Re: [RFC] How implement Secure Data Path ?
Am 08.05.2015 um 10:37 schrieb Daniel Vetter: dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. I'd generally prefer a /dev node instead of syscall, as they can be dynamically allocated (loaded as module, etc), which in turn offers more finer control (eg. for containers, etc). One could easily replace the it with its own implementation (w/o patching the kernel directly and reboot it). Actually, I'm a bit unhappy with the syscall inflation, in fact I'm not even a big friend of ioctl's - I'd really prefer the Plan9 way :p I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? Just curious (as I'm pretty new to this area): how to GEM objects and dma-bufs relate to each other ? Is it possible to directly exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: boot loader
Am 12.05.2015 um 02:17 schrieb Thiago Farina: Yeah. Maybe it was a right decision from Linus to isolate, focus and work solely on kernel and not including everything else (like FreeBSD does) that makes a usable system. Just a little sidenote: Plan9 uses a trimmed-down Kernel as bootloader, which gives interesting opportunities (eg. using various services like filesystems, shells, etc in the bootloader). With modern bootloaders like Barebox, the need for that IMHO isn't that huge anymore. OTOH, there're still several things, I'd wish to have available in the bootloader (eg. iscsi- or bnlkdev support). Anyone here, who uses a Linux kernel as bootloader / preboot environment ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: boot loader
Am 13.05.2015 um 09:02 schrieb Pavel Machek: Anyone here, who uses a Linux kernel as bootloader / preboot environment ? Yes. See kexec. Can you tell us a bit more about your setup ? Which platforms/archs are you on ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] rtc: mxc: add a second clock
Am 16.05.2015 um 00:35 schrieb Philippe Reynes: The mxc RTC needs two clocks, one for the input reference, and one for the IP. But this driver was only using one clock (for the reference). This patch add the second clock (for the IP). Does this also apply to MX53, or just MX21 ? greetings, -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
imx53 IPU support on 4.0.4
Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/21] On-demand device registration
Am 04.06.2015 um 22:39 schrieb Alexander Holler: As it seems to have been forgotten or overread, I've mentioned in my series of patches last year that, with a few changes, it's possible to let the algorithm I've used (dfs) to spit out all drivers which can be initialized in parallel. Unfortunately, I've missed that ... could you please resend you patches? Boot time reduction is one of the topics on my 2do in several weeks. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
Am 29.05.2015 um 19:36 schrieb Theodore Ts'o: Yes, it's ugly, but there still are some SOC and drivers that aren't available on newer kernels. Why so, exactly ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
Am 29.05.2015 um 17:01 schrieb Richard Weinberger: Hi, On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult weig...@melag.de wrote: Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. Enterprise distribution kernels. hmm, by enterprise you mean distros like RHEL, which even can't get a dist-upgrade right ? ;-p In that case, it's the duty of the dist vendor, to port their (often horrible) vendor patches. I wouldn't run those distros bare-metal anyways, so the need for new kernel features (eg. drivers) wouldn't that huge. Or special kernels like PREEMPT_RT. PREEMPT_RT is pretty close to upstream. There're at 4.0.5 right now, and 4.1 is still very fresh. If I'd have the need for it (actually was already considering it for our project), I'd rather port it to 4.1. (as our BSP already is at 4.1) Sometimes the vendor BSP is that horrid that a customer cannot afford to forward port it but wants recent stuff. So you need to backport... By vendor BSP, you perhaps mean certain soc or board manufacturer stuff ? Just dont use it, it's usually horrible crap anyways. These usually are fire-and-forget showcases, not suited for production use. Waste of resources. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
Am 01.06.2015 um 20:50 schrieb Felix Fietkau: We support many different platforms, and sometimes it takes a while to update the kernel on them. Just curious: what makes these platforms so different from each other, so it takes so much time to port to new kernel ? Are there things so special, that they can't go into mainline ? In a few weeks, I'll (hopefully) have a few weeks off and plan to play around w/ some spare DSL routers. Maybe we can have a talk on how to get more things mainlined, if you wish :) Using backports significantly reduces the amount of effort that we need to put into maintaining the wireless drivers. When making changes to wireless drivers or mac80211, which I submit upstream, I also develop them in our most recent backports snapshot first (typically generated from wireless-testing). When they are done, I port them to a proper git tree and submit them from there. How much has changed from your old baseline compared to current mainline ? I could imagine, in your area it might not be as much as in others (eg. graphics or v4l subsystem). In OpenWrt, we typically update the backports snapshot outside of the normal kernel release cycle (always to latest wireless-testing) and stabilize that by cherry-picking individual patches on top of it. Can you estimate the required workforce ? Some statistics on that would be really nice. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
Am 24.06.2015 um 11:19 schrieb Richard Weinberger: Hi, Porting PREEMPT_RT is not that easy. Did you ever? I know. OTOH, is backporting drivers to ancient kernels (where internal APIs often are _completely_ different) really easier ? Perhaps it might look so, if it's just one individual driver - but often it doesn't keep this way, sooner or later other things pop up. So, you rewrite all drivers and the board support from scratch? Sometimes, if I have to. Because - on my own experience - what SoC vendors provide usually is pretty unusable, just a quick showcase. Right now, I'm working on a project w/ some imx53-based board. What freescale provides here is practically unusable. Really ancient (last time I checked, it was an old 2.6.x), unsable and insecure (anybody had a closer look at their kgsl patch or their gst-plugin ?) We'll have to drop the whole idea of using the GPUs, due to lack of support - the existing driver/libgl is known to be broken and insecure, no support from fsl whatsoever, we're lacking resources for a full reverse engineering, and moving to another SoC is out of question (at least for the forseeable future). So, it ends up in having no GPU, therefore no GL/GSL, therefore no QtQuick/QML. Pavel already mentioned the correct way to go: chip vendors should provide proper (mainline'able) patches, or at least full specs. And I'll add: those who dont, should simply be boycotted. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
. CPU's opcodes, register specs on perhiphals, etc, etc). If I don't get the proper specs for that, it's pretty much useless for me. For example, on my current mx53 system, I can't use the GPUs due to lack of specs. or you build your own hardware, CPU etc. Actually, that's already in the pipeline. Will be an entirely different architecture, more like a huge transputer grid ... but that's going to be off-topic ... This interface can be very low level (eg: CPU jumps to 0x upon reset), run a little bit of code to initialize some on-chip controllers and Yes, and I need to know exactly how to do that initialization, so I can put my own firmware/bootloader in here. Maybe even an XIP kernel. You have to decide what's acceptable to you. We all do that. Yes, and I made the decision, that I can't tolerate any proprietary code - not on mission critical embedded systems. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Hi, snip let me add some personal views for backports issue in general - or, more precisely, the opposite - forward porting: Silicon vendors often just provide drivers for very old kernels, even worse: proprietary drivers, which need ugly kernel hacks (eg. Freescale is one of the worst). So I'll have to forward-port drivers to newer kernels - but I never had the practical need to backport one. Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
) for over five years while they sponsored work on a replacement. For xcode vs gcc, I dont really see any actual license _conflict_. This was an political action, and we should take it as that. Apple is against freedom. The least thing, we - the people - should do is not helping them, not giving them a single penny. When samba went gplv3, they did http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement for samba and so on. Fine. They should do so. We don't need them. We lived happily without them, and we'll continue to do so. SMB is just old legacy anyways, just for interfacing with Toy-OS. (actually, I haven't had any single Windows system for about 20 years - never missed that). The pro-gpl guys have tried various coercion tactics to get their way, which hasn't helped. The FSF sued CISCO in 2008 over the same 2003 vendor BSP that had already been beaten out of them to produce OpenWRT (and remember when I said you don't sue the upstream you sue the individual customers when maximizing your payout? No, you sue them for the biggest policitical impact. Yes: it is very much about politics. The BSP was from Broadcom, so the FSF sued Cisco). CISCO distributed the devices, that's why the primary infringenment was done by them. Of course, Boardcom should have been sued, too. Lesson: These guys will never be satisifed, No. They (more precisely: we) will be satisfied, as long as you place by the rules. And the rules are pretty clear - just read the text. And if you don't like these rules, just pick something else. The FSF also retroactively deleted binutils 2.17 (the last GPLv2 version) off their ftp site and replaced it with a binutils 2.17a containing GPLv3 code, which they symlinked from the old name. (No really. They did the same thing with gdb 6.6 except there they didn't put a symlink, http://ftp.gnu.org/gnu/gdb/ . Okay, that's a bad trick. Or just a bit stupidity. Do we have evidence that this really was on purpose ? Remember how I said qemu wanted machine definitions they could get from _which_ two packages? Well, they still can use the old ones. And if they patch anything there, they're free to decide whether to dual-license or not. QEMU went GPLv2 only to stay compatible with the kernel.) I haven't had a deeper look into QEMU source, but I wonder at which places exactly it would make sense to share / transfer code from kernel to QEMU. Any example ? and don't forget what the FSF did to Mepis http://archive09.linux.com/articles/55285 (sued them for not mirroring UNMODIFIED source tarballs readily available on the upstream website). They just were asked to comply to their part of the deal. And as they do now, no reason for whining about it anymore. The kernel is grandfathered in, in part because it's always tolerated (if not enjoyed) binary modules, Actually, I strongly believe, they shouldn't be tolerated at all. but do you really think that if Android decided time to switch to BSD it would take them longer than 18 months to port everything they care about? They re-port every kernel release... Maybe. Just let them do it if they wish. I don't really care. I gave a talk about this at Ohio LinuxFest in 2013: outline: http://landley.net/talks/ohio-2013.txt audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3 You should learn the difference between opensource and free software. -- free like freedom, not free beer. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. P.S. some of us actually care about licenses being appropriate to what they're applied to, and at least theoretically capable of being honored. Your email footer may be very slightly undermining your position here. This is just a dumb auto-generated footer, coming from my client's mail server over here ... I'm just too lazy for setting up an own MTA on my workstation. You can safely ignore that. -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten
Re: [PATCH RESEND v3 2/2] ALSA: replace CONFIG_PROC_FS with CONFIG_SND_PROC_FS
Am 27.05.2015 um 13:45 schrieb Jie Yang: We may disable proc fs only for sound part, to reduce ALSA memory footprint. So add CONFIG_SND_PROC_FS and replace the old CONFIG_PROC_FSs in alsa code. With sound proc fs disabled, we can save about 9KB memory size on X86_64 platform. For consistency, both patches should be squashed into one, IMHO. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Am 25.05.2015 um 09:14 schrieb Rob Landley: Personally, I'm sad we're starting to get ACPI for arm but if device tree data files are only available under GPL, people will hold their nose and deploy ACPI. What's the big deal with having DTS/DTB under GPL ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Am 22.05.2015 um 18:26 schrieb Rob Herring: Hi, Ideally, dtb files are shipped with firmware separately from the OS. You should be able to run multiple OS's with that dtb. There is often desire or requirements to not have GPL code in firmware. I dont see that begin shipped *with* the firmware (but still as a separate object/file) automatically means a derived work. And I actually wouldn't want dtb strictly so interewoven with the firmware/bootloader, that it can be easily extracted or replaced anymore. IMHO, we shouldn't support such vendors. (freedom is more than just $0 price) And there shouldn't be any proprietary firmware anyways. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: imx53 IPU support on 4.0.4
Am 20.05.2015 um 22:55 schrieb Russell King - ARM Linux: Hi, The way kernel development works is that patches are sent to mailing lists for review. Kernel developers review the patches and provide comments back. The comments are discussed and actioned, and a new set of patches posted for further review. This cycle repeats. Okay. I just wanted to prevent too much traffic. But I'll use git-send-email, if you prefer. When everyone is happy, the patches can be applied, or pulled from a non-github git tree. (Kernel people generally don't like github.) Why so ? This is so that upstream kernel developers don't get too overloaded with work that really should be done by downstream folk (imagine if they had to rewrite every patch that came their way...) Of course. I wasn't aware of the separate linux-media maillist at that time. By the way: I've now moved to Phillip's recent ipuv3 patches, but still have lots of others (about 30) for my tqma53-based board, which might be generic enough for going into mainline someday (many of them by ptx folks). Should I post them to lkml or somewhere else ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: imx53 IPU support on 4.0.4
Am 20.05.2015 um 15:21 schrieb Fabio Estevam: Hi, (Haven't 4.1rc* yet, as it broke some other things for me.) What are the regressions you see? Trouble w/ emmc/sd suddenly being ro. Guess, something in with the corresponding APIs changed and I didn't rebase correctly. It's now several weeks ago (IIRC, on rc1) - I'm currently rebasing everything again to the recent master. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux: What's the big deal with having DTS/DTB under GPL ? It's really quite simple. Other open source projects won't touch _our_ DTB with a barge pole through fear of GPL contamination. Which other foss projects do you have in mind ? And why should they fear poisoning ? The DTB is an entirely separate file. Just like various firmware blobs, startup scripts, etc, etc. Just shipping that file (be it in some source tarball or in the flash of some device) doesn't make everything else an derived work. Of course, the viral effect of the GPL could catch in if somebody directly compiles-in the dtb into something else (so it cant be easily separated / replaced) - but why should anybody wanna do that ? Sounds to me like defeating the whole purpose of DTB. So what we'll end up with is other projects creating their own DTB descriptions for the same hardware, with different properties (which they'll do in an effort to ensure that it isn't a derived work of the GPL version) and the whole thing turning into a right mess - and a poor experience for users because they then end up with OS specific DT files. Anybody is free do to everything on his own. Same as everybody is free to write his own kernel, etc. But I dont see a practical usecase where the GPL's viral effect could catch in here in the first place. Alternatively, as Rob points out, people will just go the ACPI route to avoid the GPL contamination problem. If they really wanna go that ugly route ... just let them go. I don't see where I could care at all. As I'm primarily concerned w/ embedded systems, I'll need full documentation and control over the device, I won't trust vendor DTBs anyways. And I won't help people doing crippled proprietary stuff, not at this critical point. Even for larger systems - except the crippled x86 world - I won't even allow any proprietary bootloader/firmware. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] remoteproc for 4.2
Am 01.07.2015 um 16:14 schrieb Ohad Ben-Cohen: The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031: Linux 4.1-rc1 (2015-04-26 17:59:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git tags/remoteproc-4.2 for you to fetch changes up to 8de3dbd0895bebe52d069a82feae8e3fb51c1bdf: remoteproc: fix !CONFIG_OF build breakage (2015-06-18 11:44:41 +0300) Just curious: could this rproc framework also be used for more specific coprocessors like the VPUs found on various SoCs ? (eg. CODA on imx53) --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 -- https://www.facebook.com/MELAG.Medizintechnik [http://www.melag.de/fbbanner.png]https://www.facebook.com/MELAG.Medizintechnik MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] drivers: Add boot constraints core
On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering devices/drivers if their drivers/devices are available or not. If yes, then the devices are probed using the drivers. Now the drivers must make sure all the dependencies are met at this point, else they can return -EPROBE_DEFER and the kernel will try probing them again. Could we somehow introduce an strict ordering ? Maybe by letting the device core know of the dependencies, before individual probe()'s explicitly ask for them ? Let's imagine a LCD panel driven by a regulator behind SPI. The panel driver would ask the regulator framework to switch on, which would call the regulator driver. This one now would talk to SPI framework, which finally calls the SPI driver. If SPI isn't up yet, it would all be deferred, leaving the panel driver uninitialized (tried again later). This should happen in probe, otherwise we are screwed. Yes, but the probe result may be deferred, so it's tried again in the next round. Correct ? If the bootloader already switched on the panel (therefore already enabled SPI), why does it matter that the panel driver isn't up yet ? But the kernel doesn't know how it is configured, there can be so many configurable parameters. The kernel needs to do it again by itself. Could it read back the config ? By the way: I've got a similar problem w/ gpmc right now: uboot already sets it up, but the kernel only knows about one CS (for the nand) and screwes up the others (eg. fpga), so it cant access the fpga . Until I've sorted out all the parameters for DT (unfortunately, only have the raw register values), I'll have to rely on an userland test program to set it all up ... Let me try with an example. A regulator is shared between LCD and DMA controller. Operable ranges of the regulator: 1.8 - 3.0 V Range required by LCD: 2.0 - 3.0 V Range required by DMA: 1.8 - 2.5 V Would a config readback help here ? The regulator core then should know that we're already in proper range for DMA and no need to touch the regulator. --mtx
Best practise for a polling device driver ?
Hi folks, I'm currently writing a driver for an (pseudo-)serial device (actually, a bunch of HW fifo's, which look like serial controllers to the host), which only supports polling, no interrupts. So far, I'm just using a kthread in a loop, but that would have to run w/ high priority sleep very short (needs to transfer several MB/s on a am33xx), so probably not a good idea. Another option could be using timers for just looking at the status registers and issue sw interrupts, which are then handled just like the w/ the usual interrupt-driven serial ports (IOW: mimic an interrupt controller). What do you folks thinkt about that ? thx. --mtx
Re: Directly accessing serial ports from drivers w/o TTYs ?
On 26.06.2017 14:51, Alan Cox wrote: Hi, You can write your own driver for the physical hardware and claim it in your driver. Shouldn't normally be needed except for bizarre cases when a serial link is used for something very non tty like (eg as GPIO lines). In my case, it's not really a serial link, but an backplane w/ FIFOs, which looks like a serial ports to the host (AFAIK, historically coming from older systems which actually had various serial controllers, eg. rs232, rs485/mvb, etc). The backplane seems to simulate the lower layers of an mvb network. Otherwise all the low level tty device locking, queues and interfaces assume there is a tty_struct attached to it, so yes you need a tty struct. I was thinking about something that looks like serdev from consumer side, but instead directly works on struct uart_port, w/o actually allocating a tty (and also the funny things like signals, etc). Why do you need to do otherwise ? Maybe it could offer better performance ? --mtx
Re: [RFC 0/5] drivers: Add boot constraints core
On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just curious: aren't the devices (at least w/ DT) only initialized after dependencies (eg. regulators) are already up ? Let's imagine a LCD panel driven by a regulator behind SPI. The panel driver would ask the regulator framework to switch on, which would call the regulator driver. This one now would talk to SPI framework, which finally calls the SPI driver. If SPI isn't up yet, it would all be deferred, leaving the panel driver uninitialized (tried again later). Am I wrong here ? If the bootloader already switched on the panel (therefore already enabled SPI), why does it matter that the panel driver isn't up yet ? Is there anything that accidentially switches it off again (eg. by resetting the regulator) ? If so, shouldn't the corresponding drivers make sure that all depencies are met before doing anyhing w/ the device, not even attempting a reset ? --mtx
Re: [RFC 0/5] drivers: Add boot constraints core
On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very colourful. Could the bootloader pass safe (or blocked) memory regions to the decompressor ? --mtx
[PATCH] include: platform_device: add pdev_info(), pdev_warn, ... convencience macros
--- include/linux/platform_device.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 98c2a7c7108e..723c209d3760 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -368,4 +368,11 @@ extern int platform_pm_restore(struct device *dev); #define USE_PLATFORM_PM_SLEEP_OPS #endif +#define pdev_crit(pdev, fmt, args...) dev_crit(>dev, fmt, ##args) +#define pdev_err(pdev, fmt, args...) dev_err(>dev, fmt, ##args) +#define pdev_warn(pdev, fmt, args...) dev_warn(>dev, fmt, ##args) +#define pdev_notice(pdev, fmt, args...)dev_notice(>dev, fmt, ##args) +#define pdev_info(pdev, fmt, args...) dev_info(>dev, fmt, ##args) +#define pdev_debug(pdev, fmt, args...) dev_debug(>dev, fmt, ##args) + #endif /* _PLATFORM_DEVICE_H_ */ -- 2.11.0.rc0.7.gbe5a750
printk + errno texts
Hi folks, I'd like to introduce a new printk() conversion which prints out errno values as readable text. Where are these things defined ? I'd guess the actual translation must be somewhere in lib/vsprintf.c, but where are the format string checks defined ? thx --mtx
[PATCH] lib: vsprintf: add printf format conversion %M for errno strings
Adding a new format conversion for *printf() and friends.
If CONFIG_ERRNO_PRINTF_VERBOSE is enabled, prints human-readable
strerror()-like texts, otherwise just the number.
---
lib/Kconfig| 19 +++
lib/vsprintf.c | 172 -
2 files changed, 189 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index 0c8b78a9ae2e..b28ab2162435 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -7,6 +7,25 @@ config BINARY_PRINTF
menu "Library routines"
+config ERRNO_PRINTF
+ bool "printf conversion %M for errno codes"
+ default n
+ help
+ This option adds an %M modifier for *printf() for errno values.
+ (and callers like printk() etc)
+
+ In conjunction with ERRNO_PRINTF_VERBOSE, it prints human readable
+ strerror()-like textsm, otherwise just numeric values
+
+config ERRNO_PRINTF_VERBOSE
+ bool "Verbose errno strings"
+ default y
+ depends on ERRNO_PRINTF
+ help
+ Enable verbose error strings for ERRNO_PRINTF.
+
+ Small embedded systems might disable it for reducing kernel size.
+
config RAID6_PQ
tristate
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 2d41de3f98a1..9778e17fc178 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -382,7 +382,8 @@ enum format_type {
FORMAT_TYPE_UINT,
FORMAT_TYPE_INT,
FORMAT_TYPE_SIZE_T,
- FORMAT_TYPE_PTRDIFF
+ FORMAT_TYPE_PTRDIFF,
+ FORMAT_TYPE_ERRNO,
};
struct printf_spec {
@@ -600,6 +601,164 @@ char *string(char *buf, char *end, const char *s, struct
printf_spec spec)
return widen_string(buf, len, end, spec);
}
+#if IS_ENABLED(CONFIG_ERRNO_PRINTF_VERBOSE)
+static noinline_for_stack
+const char *errno_to_str(int no)
+{
+ switch (no) {
+ case 0: return "Success";
+ case EPERM: return "Operation not permitted";
+ case ENOENT:return "No such file or directory";
+ case ESRCH: return "No such process";
+ case EINTR: return "Interrupted system call";
+ case EIO: return "I/O error";
+ case ENXIO: return "No such device or address";
+ case E2BIG: return "Argument list too long";
+ case ENOEXEC: return "Exec format error";
+ case EBADF: return "Bad file number";
+ case ECHILD:return "No child processes";
+ case EAGAIN:return "Try again";
+ case ENOMEM:return "Out of memory";
+ case EACCES:return "Permission denied";
+ case EFAULT:return "Bad address";
+ case ENOTBLK: return "Block device required";
+ case EBUSY: return "Device or resource busy";
+ case EEXIST:return "File exists";
+ case EXDEV: return "Cross-device link";
+ case ENODEV:return "No such device";
+ case ENOTDIR: return "Not a directory";
+ case EISDIR:return "Is a directory";
+ case EINVAL:return "Invalid argument";
+ case ENFILE:return "File table overflow";
+ case EMFILE:return "Too many open files";
+ case ENOTTY:return "Not a typewriter";
+ case ETXTBSY: return "Text file busy";
+ case EFBIG: return "File too large";
+ case ENOSPC:return "No space left on device";
+ case ESPIPE:return "Illegal seek";
+ case EROFS: return "Read-only file system";
+ case EMLINK:return "Too many links";
+ case EPIPE: return "Broken pipe";
+ case EDOM: return "Math argument out of domain of func";
+ case ERANGE:return "Math result not representable";
+ case EDEADLK: return "Resource deadlock would occur";
+ case ENAMETOOLONG: return "File name too long";
+ case ENOLCK:return "No record locks available";
+ case ENOSYS:return "Invalid system call number";
+ case ENOTEMPTY: return "Directory not empty";
+ case ELOOP: return "Too many symbolic links encountered";
+ case ENOMSG:return "No message of desired type";
+ case EIDRM: return "Identifier removed";
+ case ECHRNG:return "Channel number out of range";
+ case EL2NSYNC: return "Level 2 not synchronized";
+ case EL3HLT:return "Level 3 halted";
+ case EL3RST:return "Level 3 reset";
+ case ELNRNG:return "Link number out of range";
+ case EUNATCH: return "Protocol driver not attached";
+ case ENOCSI:return "No CSI structure available";
+ case EL2HLT:return "Level 2 halted";
+
Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings
On 25.06.2017 19:27, Joe Perches wrote: > Every use of %M is going to cause gcc when using __printf to emit > a warning like: > > unknown conversion type character ‘M’ in format [-Wformat=] Yeah, that's still an open problem. Actually, I still haven't found out, how it's done w/ all the other kernel-internal conversions. I was under the impression, there was some magic to tell the compiler which letters correspond to which types - unfortunately, didn't find anything like that. Is that really hardcoded in gcc ? > Beyond that, why is this useful? Use that instead of %d where errno values are printed/logged. > There can't possibly be any fast-path use. I'm using it eg. for driver development - always having to look up the numbers is quite ugly and time consuming. > Why not just create a function that does errno/string conversions? Already was about to do so. Shall I call it strerror() ? --mtx -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287
Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings
On 25.06.2017 22:10, Joe Perches wrote: >> Yeah, that's still an open problem. Actually, I still haven't found out, >> how it's done w/ all the other kernel-internal conversions. > > Everything else uses "%p", hmm, but errno's aren't pointers. Isn't %p checked for pointer values ? >> Already was about to do so. Shall I call it strerror() ? > > I presume kstrerror > > So use something like > "%d: (%s)", errno, kstrerror(errno) Okay, sounds good. --mtx
RFC: abstraction for RPC'ish hardware drivers ? mailbox ? netif ?
Hi folks, I'm currently implementing drivers for an industrial backplane, (*1) which uses some kind of rpc / command-response mechanism. There're different variants, eg. some proprietary serial interface, USB link, pci cards, etc. On top of that there's a block-based command- response mechanism for talking to the individual cards (which may have multiple channels). In the device I'm currently working on, we have several cards, eg. CPU, PMU (power supply) and several IO modules. My primary goal is docking in the IO cards into IIO (and later the PMU into the power management infrastructure). So, I need layers: the serial port (using uart stuff), the packet layer and IIO. (and wire them via DT) I see two possible candidates here: a) mailbox b) network interface Both of them seem to be a good fit for packet-based interfaces, but the network layer might be too much overhead, and (IMHO) doesn't seem to be suited for direct use from (non network-protocol) drivers. What do you folks think ? --mtx -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287
Directly accessing serial ports from drivers w/o TTYs ?
Hi folks, is there already a way for accessing serial ports from drivers, w/o having to go through the TTY subsystem ? Serdev seems provide a connection between arbitrary TTYs to device drivers. But this implies always having a TTY for each UART (even if it's never used outside the kernel). Is there any way for accessing uarts more directly ? --mtx -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287
Re: [PATCH] lib: vsprintf: add printf format conversion %M for errno strings
On 26.06.2017 00:47, Randy Dunlap wrote: > but why not just do that in userspace. Patch up syslogd (which one, actually?) to decode all the dozens of different cases that print out errno values ? Applying your argument more consequently - why do we have human-readable messages at all, instead of just writing out message IDs as hexdumps or binary stream (would make the kernel a lot smaller) ? > but there's not really much need for it to be in the mainline kernel. The idea was having a generic and convenient solution that can be used by other parts of the kernel, too. (just like w/ all the other logging helpers). That's also the reason why I added into vsprintf(). > So when your driver prints "blah: foo bar error 49", > just run a little program that converts 49 to . How could that help when userland isn't even up yet ? --mtx -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287
imx6: CSI for ADCs (fpga)
Hi folks, did anyone already use the imx6's csi port for anything other than cameras ? I'm thinking about using it for an ADC (in fpga). Theoretically it should be possible to transfer non-video data, but the question here is whether the ipu might interfer here (eg. trying colorspace conversions, etc). --mtx
dtc: imx6 warnings on unit address format errors
Hi folks,
I'm getting lots of warnings from dtc about unit address format errors:
For example in imx6q.dtsi:
ocram: sram@0090 {
The node name's address part has leading zeros which dtc doesn't like.
It doesn't seem to have a big influence (yet ?), but I'd guess this
warning is there for a reason.
Should we fix this ?
--mtx
Re: Proposal: single defconfig for all ARM
On 26.10.2017 18:26, Pintu Kumar wrote: Hi, My proposal is to maintain a common base defconfig file for all ARM products and only add the additional configs in the new defconfig file. I am not sure if this is already possible. If this is possible please let us know the steps. Would cat'ing 'em together do the trick ? OTOH, we could introduce meta-options in a separate menu, that just enable the actual ones. eg: --> Select SoC type --> imx6 series --> imx6 model: imx6q, imx6dl, imx6ul, ... --> enable networking --> enable lcd display --> enable hdmi display --> enable sdma --> enable usb ... --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
gpio + separate interrupts on rising / falling
Hi folks, I've got device with some strange device that triggers two irqs via one line. Rising means buffer A filled, falling mean buffer B filled. I'd like to handle that via two separate interrupts. Is it possible to register both an rising and an falling edge irq on the same line ? --mtx
p9caps: add Plan9 capability devices
v2 of the p9caps patch
[PATCH] p9caps: add Plan9 capability devices
From: "Enrico Weigelt, metux IT consult" <i...@metux.net>
This driver implements the Plan9 capability devices, used for
switching user id via capability tokens.
https://9p.io/sys/doc/auth.html
---
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile| 1 +
drivers/staging/p9caps/Kconfig | 11 ++
drivers/staging/p9caps/Makefile | 1 +
drivers/staging/p9caps/p9caps.c | 369
5 files changed, 384 insertions(+)
create mode 100644 drivers/staging/p9caps/Kconfig
create mode 100644 drivers/staging/p9caps/Makefile
create mode 100644 drivers/staging/p9caps/p9caps.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 554683912cff..23f325339fe8 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/p9caps/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 6e536020029a..eccdf4643453 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -3,6 +3,7 @@
obj-y += media/
obj-y += typec/
+obj-$(CONFIG_PLAN9CAPS)+= p9caps/
obj-$(CONFIG_IRDA) += irda/net/
obj-$(CONFIG_IRDA) += irda/drivers/
obj-$(CONFIG_PRISM2_USB) += wlan-ng/
diff --git a/drivers/staging/p9caps/Kconfig b/drivers/staging/p9caps/Kconfig
new file mode 100644
index ..b909daaa79ce
--- /dev/null
+++ b/drivers/staging/p9caps/Kconfig
@@ -0,0 +1,11 @@
+config PLAN9CAPS
+ tristate "Plan 9 capability device"
+ default n
+ select CRYPTO_HMAC
+ select CRYPTO_SHA1
+ help
+ This module implements the Plan 9 capability devices
+ /dev/caphash and /dev/capuse
+
+ To compile this driver as a module, choose
+ M here: the module will be called p9caps.
diff --git a/drivers/staging/p9caps/Makefile b/drivers/staging/p9caps/Makefile
new file mode 100644
index ..67d38099a249
--- /dev/null
+++ b/drivers/staging/p9caps/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PLAN9CAPS)+= p9caps.o
diff --git a/drivers/staging/p9caps/p9caps.c b/drivers/staging/p9caps/p9caps.c
new file mode 100644
index ..e46b09821c18
--- /dev/null
+++ b/drivers/staging/p9caps/p9caps.c
@@ -0,0 +1,369 @@
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Plan9 /dev/caphash and /dev/capuse device
+ *
+ * 2DO: - caphash should only allow one process (per userns)
+ * - support textual user names
+ * - invalidate old caps
+ */
+
+#define DEVICE_CAPUSE "/dev/capuse"
+#define DEVICE_CAPHASH "/dev/caphash"
+
+struct caphash_entry {
+ struct list_head list;
+ struct user_namespace *user_ns;
+ char data[SHA1_DIGEST_SIZE];
+};
+
+struct caphash_writer {
+ struct list_head list;
+ struct user_namespace *user_ns;
+};
+
+static dev_t caphash_devid = 0;
+static dev_t capuse_devid = 0;
+
+static LIST_HEAD(caphash_entries);
+static LIST_HEAD(caphash_writers);
+
+static DEFINE_MUTEX(lock);
+
+struct crypto_ahash *hmac_tfm = NULL;
+
+static int caphash_open(struct inode *inode, struct file *filp)
+{
+ struct caphash_writer *tmp = NULL;
+ struct user_namespace *user_ns = current_user_ns();
+ int retval = 0;
+ struct list_head *pos, *q;
+
+ /* make sure only one instance per namespace can be opened */
+ mutex_lock();
+
+ list_for_each_safe(pos, q, &(caphash_writers)) {
+ tmp = list_entry(pos, struct caphash_writer, list);
+ if (tmp->user_ns == user_ns) {
+ pr_err("already locked in this namespace\n");
+ retval = -EBUSY;
+ goto out;
+ }
+ }
+
+ if (!(tmp = kzalloc(sizeof(struct caphash_writer), GFP_KERNEL))) {
+ retval = -ENOMEM;
+ goto out;
+ }
+
+ tmp->user_ns = get_user_ns(user_ns);
+ list_add(&(tmp->list), _writers);
+
+out:
+ mutex_unlock();
+ return retval;
+}
+
+static int caphash_release(struct inode *inode, struct file *filp)
+{
+ int retval = 0;
+ struct user_namespace *user_ns = current_user_ns();
+ struct list_head *pos, *q;
+ struct caphash_entry *tmp;
+
+ mutex_lock();
+
+ list_for_each_safe(pos, q, &(caphash_writers)) {
+ tmp = list_entry(pos, struct caphash_entry, list);
+ if (tmp->user_ns == user_ns) {
+ list_del(pos);
+ kfree(tmp);
+ goto out;
+ }
+ }
+
+out:
+ mutex
Re: RFC: build config via DT names
On 12.02.2018 23:24, Frank Rowand wrote: There is a tool to aid this process: scripts/dtc/dt_to_config. It is not a 100% solution, but it is very helpful. The problem is difficult enough that this tool led to a conference talk. The slides are at https://elinux.org/images/5/50/Dt_debugging_part_2.pdf which is linked to from https://elinux.org/Device_Tree_presentations_papers_articles#linux_kernel_configuration I believe my approach can make this much simpler, at least for most drivers: the maintainers would explicitly add proper config flags, instead of letting the tool guess it. Of course, it would take some amount of work to do that for all drivers, but we could do that step by step. --mtx
Re: [PATCH] p9caps: add Plan9 capability devices
On 13.02.2018 07:16, Serge E. Hallyn wrote: + /* make sure only one instance per namespace can be opened */ > > ... at a time yeah, right. might be better to keep this state in the user_ns itself, would avoid kzalloc below. thought about, but hesitated to touch user_ns. might not be the best idea when having p9caps as module (OTOH, doesn't need to be a module) the whole thing might become a bit more complex when introducing plan9-like unprivileged mount operations. haven't sorted out how to do that yet. Would it be worth doing any privilege checking here? Which ones should I check ? --mtx
user_namespace: add aux data
Hi folks, is there any way for drivers to add aux data to user namespaces ? I'm currently implementing plan9-like capabilities authentication, and I'd like to keep this separate by user-ns. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
RFC: build config via DT names
Hi folks, I've regularily have the task of configuring a kernel for a given DT. To make this a little bit easier, I'd like to do this automatically. The tuff task here is getting a mapping between dt compatible strings and corresponding CONFIG_* flags. Automatically extracting it from the source code seems pretty tricky, especially w/ corner cases (eg. some drivers support groups of devices, depending on config options) - IMHO it will need some code changes anyways. Therefore I propose a simple approach using the existing Kconfig system: Add an extra (toplevel) menu and config flag naming scheme which directly map DT compatible strings to config flags. For example: > fsl,mpc5200-gpio <=> CONFIG_DTDEV_FSL_MPC5200_GPIO > config CONFIG_DTDEV_FSL_MPC5200_GPIO >tristate "fsl,mpc5200-gpio" >select GPIO_MPC5200 Note that these flags are separate from the actual drivers - they just enable them automatically. Of course they'll have to be maintained by the driver maintainers. What do you think about this idea ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
[PATCH] p9caps: add Plan9 capability devices
From: "Enrico Weigelt, metux IT consult" <i...@metux.net>
This driver implements the Plan9 capability devices, used for
switching user id via capability tokens.
https://9p.io/sys/doc/auth.html
---
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile| 1 +
drivers/staging/p9caps/Kconfig | 11 ++
drivers/staging/p9caps/Makefile | 1 +
drivers/staging/p9caps/p9caps.c | 371
5 files changed, 386 insertions(+)
create mode 100644 drivers/staging/p9caps/Kconfig
create mode 100644 drivers/staging/p9caps/Makefile
create mode 100644 drivers/staging/p9caps/p9caps.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 554683912cff..23f325339fe8 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/p9caps/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 6e536020029a..eccdf4643453 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -3,6 +3,7 @@
obj-y += media/
obj-y += typec/
+obj-$(CONFIG_PLAN9CAPS)+= p9caps/
obj-$(CONFIG_IRDA) += irda/net/
obj-$(CONFIG_IRDA) += irda/drivers/
obj-$(CONFIG_PRISM2_USB) += wlan-ng/
diff --git a/drivers/staging/p9caps/Kconfig b/drivers/staging/p9caps/Kconfig
new file mode 100644
index ..455c3fa726ff
--- /dev/null
+++ b/drivers/staging/p9caps/Kconfig
@@ -0,0 +1,11 @@
+config PLAN9CAPS
+ tristate "Plan 9 capability device"
+ default n
+ select CRYPTO_HMAC
+ select CRYPTO_SHA1
+ help
+ This module implements the Plan 9 capability devices
+ /dev/caphash and /dev/capuse
+
+ To compile this driver as a module, choose
+ M here: the module will be called p9auth.
diff --git a/drivers/staging/p9caps/Makefile b/drivers/staging/p9caps/Makefile
new file mode 100644
index ..67d38099a249
--- /dev/null
+++ b/drivers/staging/p9caps/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PLAN9CAPS)+= p9caps.o
diff --git a/drivers/staging/p9caps/p9caps.c b/drivers/staging/p9caps/p9caps.c
new file mode 100644
index ..4c5c94dc1893
--- /dev/null
+++ b/drivers/staging/p9caps/p9caps.c
@@ -0,0 +1,371 @@
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Plan9 /dev/caphash and /dev/capuse device
+ *
+ * 2DO: - caphash should only allow one process (per userns)
+ * - support textual user names
+ * - invalidate old caps
+ */
+
+#define DEVICE_CAPUSE "/dev/capuse"
+#define DEVICE_CAPHASH "/dev/caphash"
+
+#define MODNAME"p9cap"
+
+struct caphash_entry {
+ struct list_head list;
+ struct user_namespace *user_ns;
+ char data[SHA1_DIGEST_SIZE];
+};
+
+struct caphash_writer {
+ struct list_head list;
+ struct user_namespace *user_ns;
+};
+
+static dev_t caphash_devid = 0;
+static dev_t capuse_devid = 0;
+
+static LIST_HEAD(caphash_entries);
+static LIST_HEAD(caphash_writers);
+
+static DEFINE_MUTEX(p9cap_lock);
+
+struct crypto_ahash *p9cap_tfm = NULL;
+
+static int caphash_open(struct inode *inode, struct file *filp)
+{
+ struct caphash_writer *tmp = NULL;
+ struct user_namespace *user_ns = current_user_ns();
+ int retval = 0;
+ struct list_head *pos, *q;
+
+ /* make sure only one instance per namespace can be opened */
+ mutex_lock(_lock);
+
+ list_for_each_safe(pos, q, &(caphash_writers)) {
+ tmp = list_entry(pos, struct caphash_writer, list);
+ if (tmp->user_ns == user_ns) {
+ printk(KERN_ERR DEVICE_CAPHASH ": already locked in
this namespace\n");
+ retval = -EBUSY;
+ goto out;
+ }
+ }
+
+ if (!(tmp = kzalloc(sizeof(struct caphash_writer), GFP_KERNEL))) {
+ retval = -ENOMEM;
+ goto out;
+ }
+
+ tmp->user_ns = get_user_ns(user_ns);
+ list_add(&(tmp->list), _writers);
+
+out:
+ mutex_unlock(_lock);
+ return retval;
+}
+
+static int caphash_release(struct inode *inode, struct file *filp)
+{
+ int retval = 0;
+ struct user_namespace *user_ns = current_user_ns();
+ struct list_head *pos, *q;
+ struct caphash_entry *tmp;
+
+ mutex_lock(_lock);
+
+ list_for_each_safe(pos, q, &(caphash_writers)) {
+ tmp = list_entry(pos, struct caphash_entry, list);
+ if (tmp->user_ns == user_ns) {
+ list_del(pos);
+
adding plan9-like usernames to the kernel
Hi folks, as part as a little research project for bringing Plan9 semantics to Linux, I'd like to add textual usernames. In contrast to *nix, Plan9 doesn't use numerical IDs, but names. Obviously that needs some internal mapping between names and ids. Should this go into struct user_namespace (where per-namespace uid mapping lives) or to struct cred / struct user_struct ? The primary consumer of this username will be the /dev/caphash and /dev/capuse devices for switching the UID. (an interesting question of course is, how to allocate the numerical UIDs for given usernames) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
ce to mainline anytime soon. But that shouldn't even matter. Solving a specific problem and fitting in something into the big generic world are two entirely different things. Many great things (eg. various container subsystems, realtime, android stuff, ...) went a long way towards mainline, some still have a long way to go. That's just because it's these topics are far from being trivial. And that shouldn't stop anybody. > If I understand the context correctly, the previous "regime" could be > the culprit, at least to some extent, why still don't have the VM > look containers with vanilla. Why exactly do you think so ? What exactly are you missing here ? Where's the connection to social rules ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
On 04.10.2018 16:57, Eric W. Biederman wrote: > Very often people will propose patches that do solve their specific case > but only do 10% or maybe 20% of what is needed for a general kernel > level solution. For something that just works and does not cause > maintenance problems in the long run. One of the cases is the hard realtime stuff. A perfect implementation for hard-RT environments can easily turn out as total crap for generic server workloads. So, these things really take time make both worlds fit together. For those cases, it's often better to maintain it as a separate tree/patchset and step by step try to bring those pieces to mainline, that fit in there. > I know many other maintainers get hit with such a stream of bad > container ideas that they tend to stop listening. As their priorities > are elsewhere I don't blame them. Let's put it that way: these ideas probaly aren't necessarily bad as such, but just don't fit into mainline (yet). OVZ is such a case: it's s good thing for a range of usecases, and pretty successful there. But it conflicts lots of other places that the mainline has to support. Therefore it has to stay a separate tree, until we've found a better solution, somewhere in the future. > Similarly because maintainers have a limited amount of time there are no > guarantees how much we can help others. We can try but people have to > meet maintainers at least half way in figuring out how things work > themselves, and sometimes there is just not enough time to say anything. Yes. I've been demotivated by this problem myself. But I know, I can't expect anybody else do to my homework for me. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Linux 4.19-rc4 released, an apology, and a maintainership note
On 16.09.2018 21:22, Linus Torvalds wrote: Hi, > One was simply my own reaction to having screwed up my scheduling of > the maintainership summit: yes, I was somewhat embarrassed about > having screwed up my calendar, but honestly, I was mostly hopeful that > I wouldn't have to go to the kernel summit that I have gone to every > year for just about the last two decades. IMHO, if you - for whatever reason - want to skip a conference, it's your right to do so. You've done so much for us, you deserve a break. > This is my reality. I am not an emotionally empathetic kind of person > and that probably doesn't come as a big surprise to anybody. Least of > all me. The fact that I then misread people and don't realize (for > years) how badly I've judged a situation and contributed to an > unprofessional environment is not good. I, personally, never felt the Linux kernel community was anything like an unprofessional environment in any way. Quite the opposite. Certainly, there's room for improvement here and there, but IMHO, the general situation is the best of all projects I've been involved in. Don't be so hard on yourself. > This week people in our community confronted me about my lifetime of > not understanding emotions. My flippant attacks in emails have been > both unprofessional and uncalled for. Especially at times when I made > it personal. In my quest for a better patch, this made sense to me. > I know now this was not OK and I am truly sorry. Maybe I've missed these mails you're referring to, but I didn't see anything which IMHO wasn't justified. Even if you'd call a patch of mine "the greatest bullshit i've ever seen", I wouldn't consider this a personal attack for a ns. Because I know I would have come from a completely different perspective than mine. > The above is basically a long-winded way to get to the somewhat > painful personal admission that hey, I need to change some of my > behavior, and I want to apologize to the people that my personal > behavior hurt and possibly drove away from kernel development > entirely. I don't know anybody of these people personally, so I won't judge on that. I've just seen some blog posts, which looked pretty subjective to me and didn't tell what exactly happened. My theory is that people took things personal, which haven't been personal at all. But that seems to be a general problem, which is far out of scope of any professional software project. > This is not some kind of "I'm burnt out, I need to just go away" > break. I'm not feeling like I don't want to continue maintaining > Linux. Quite the reverse. I very much *do* want to continue to do > this project that I've been working on for almost three decades. :) > And yes, some of it might be "just" tooling. Maybe I can get an email > filter in place so at when I send email with curse-words, they just > won't go out. Because hey, I'm a big believer in tools, and at least > _some_ problems going forward might be improved with simple > automation. In that case, I doubt it's a matter of tooling. It would require a kind of artificial intelligence, that hasn't been invented yet. NP complete problem. If you really feel, your reactions on certain things, your way of communication was a problem, then I'd raise the question why such feelings, that trigger these reactions, come into your mind in the first place. I've been through something similar. I easily got angry about by bad code and people not understanding things I considered self-evident. And in my case, it actually escalated onto the personal level. My approach was self-monitoring of my feelings and behaviour. Whenever I felt my blood presure reasing, I took a cigarette break and thought about why I'm thinking that way now. Usually, I came to the conclusion that these folks who did some crap again, just don't know better, they never seen what I've seen. And it's my job to train them. This way of thinking helped me a lot, maybe it could help you and all there other, too. > I know when I really look “myself in the mirror” it will be clear it's > not the only change that has to happen, but hey... You can send me > suggestions in email. Unfortunately, I have no idea, what exactly you've seen in the mirror. I can only judge on what I've seen here in the last decades. And I like you exactly that way. Especially the rude part, eg. when it's about corporations like NVidia, or people who try to refit the Kernel for their broken userland stuff. If I may propose a patches to your /dev/brain, the only issue would be 100% strict GPL enforcement ;-) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
imx6: CSI for ADCs (fpga)
Hi folks, did anyone already use the imx6's csi port for anything other than cameras ? I'm thinking about using it for an ADC (in fpga). Theoretically it should be possible to transfer non-video data, but the question here is whether the ipu might interfer here (eg. trying colorspace conversions, etc). --mtx
Re: [PATCH] p9caps: add Plan9 capability devices
On 13.02.2018 07:16, Serge E. Hallyn wrote: + /* make sure only one instance per namespace can be opened */ > > ... at a time yeah, right. might be better to keep this state in the user_ns itself, would avoid kzalloc below. thought about, but hesitated to touch user_ns. might not be the best idea when having p9caps as module (OTOH, doesn't need to be a module) the whole thing might become a bit more complex when introducing plan9-like unprivileged mount operations. haven't sorted out how to do that yet. Would it be worth doing any privilege checking here? Which ones should I check ? --mtx
Re: RFC: build config via DT names
On 12.02.2018 23:24, Frank Rowand wrote: There is a tool to aid this process: scripts/dtc/dt_to_config. It is not a 100% solution, but it is very helpful. The problem is difficult enough that this tool led to a conference talk. The slides are at https://elinux.org/images/5/50/Dt_debugging_part_2.pdf which is linked to from https://elinux.org/Device_Tree_presentations_papers_articles#linux_kernel_configuration I believe my approach can make this much simpler, at least for most drivers: the maintainers would explicitly add proper config flags, instead of letting the tool guess it. Of course, it would take some amount of work to do that for all drivers, but we could do that step by step. --mtx
adding plan9-like usernames to the kernel
Hi folks, as part as a little research project for bringing Plan9 semantics to Linux, I'd like to add textual usernames. In contrast to *nix, Plan9 doesn't use numerical IDs, but names. Obviously that needs some internal mapping between names and ids. Should this go into struct user_namespace (where per-namespace uid mapping lives) or to struct cred / struct user_struct ? The primary consumer of this username will be the /dev/caphash and /dev/capuse devices for switching the UID. (an interesting question of course is, how to allocate the numerical UIDs for given usernames) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Directly accessing serial ports from drivers w/o TTYs ?
On 26.06.2017 14:51, Alan Cox wrote: Hi, You can write your own driver for the physical hardware and claim it in your driver. Shouldn't normally be needed except for bizarre cases when a serial link is used for something very non tty like (eg as GPIO lines). In my case, it's not really a serial link, but an backplane w/ FIFOs, which looks like a serial ports to the host (AFAIK, historically coming from older systems which actually had various serial controllers, eg. rs232, rs485/mvb, etc). The backplane seems to simulate the lower layers of an mvb network. Otherwise all the low level tty device locking, queues and interfaces assume there is a tty_struct attached to it, so yes you need a tty struct. I was thinking about something that looks like serdev from consumer side, but instead directly works on struct uart_port, w/o actually allocating a tty (and also the funny things like signals, etc). Why do you need to do otherwise ? Maybe it could offer better performance ? --mtx
Best practise for a polling device driver ?
Hi folks, I'm currently writing a driver for an (pseudo-)serial device (actually, a bunch of HW fifo's, which look like serial controllers to the host), which only supports polling, no interrupts. So far, I'm just using a kthread in a loop, but that would have to run w/ high priority sleep very short (needs to transfer several MB/s on a am33xx), so probably not a good idea. Another option could be using timers for just looking at the status registers and issue sw interrupts, which are then handled just like the w/ the usual interrupt-driven serial ports (IOW: mimic an interrupt controller). What do you folks thinkt about that ? thx. --mtx
Re: [RFC 0/5] drivers: Add boot constraints core
On 28.06.2017 10:26, Viresh Kumar wrote: Hi, Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. Just curious: aren't the devices (at least w/ DT) only initialized after dependencies (eg. regulators) are already up ? Let's imagine a LCD panel driven by a regulator behind SPI. The panel driver would ask the regulator framework to switch on, which would call the regulator driver. This one now would talk to SPI framework, which finally calls the SPI driver. If SPI isn't up yet, it would all be deferred, leaving the panel driver uninitialized (tried again later). Am I wrong here ? If the bootloader already switched on the panel (therefore already enabled SPI), why does it matter that the panel driver isn't up yet ? Is there anything that accidentially switches it off again (eg. by resetting the regulator) ? If so, shouldn't the corresponding drivers make sure that all depencies are met before doing anyhing w/ the device, not even attempting a reset ? --mtx
Re: [RFC 0/5] drivers: Add boot constraints core
On 29.06.2017 12:49, Russell King - ARM Linux wrote: The location of the frame buffer is unknown to the decompressor - and as the decompressor self-relocates itself (using purely assembly code), it could relocate itself on top of the frame buffer, causing the "nice" image to become very colourful. Could the bootloader pass safe (or blocked) memory regions to the decompressor ? --mtx
Re: [RFC 0/5] drivers: Add boot constraints core
On 29.06.2017 14:47, Viresh Kumar wrote: No. Drivers are registered to the kernel (randomly, though we can know their order) and devices are registered separately (platform/amba devices get registered automatically with DT, hint: drivers/of/platform.c). The device core checks while registering devices/drivers if their drivers/devices are available or not. If yes, then the devices are probed using the drivers. Now the drivers must make sure all the dependencies are met at this point, else they can return -EPROBE_DEFER and the kernel will try probing them again. Could we somehow introduce an strict ordering ? Maybe by letting the device core know of the dependencies, before individual probe()'s explicitly ask for them ? Let's imagine a LCD panel driven by a regulator behind SPI. The panel driver would ask the regulator framework to switch on, which would call the regulator driver. This one now would talk to SPI framework, which finally calls the SPI driver. If SPI isn't up yet, it would all be deferred, leaving the panel driver uninitialized (tried again later). This should happen in probe, otherwise we are screwed. Yes, but the probe result may be deferred, so it's tried again in the next round. Correct ? If the bootloader already switched on the panel (therefore already enabled SPI), why does it matter that the panel driver isn't up yet ? But the kernel doesn't know how it is configured, there can be so many configurable parameters. The kernel needs to do it again by itself. Could it read back the config ? By the way: I've got a similar problem w/ gpmc right now: uboot already sets it up, but the kernel only knows about one CS (for the nand) and screwes up the others (eg. fpga), so it cant access the fpga . Until I've sorted out all the parameters for DT (unfortunately, only have the raw register values), I'll have to rely on an userland test program to set it all up ... Let me try with an example. A regulator is shared between LCD and DMA controller. Operable ranges of the regulator: 1.8 - 3.0 V Range required by LCD: 2.0 - 3.0 V Range required by DMA: 1.8 - 2.5 V Would a config readback help here ? The regulator core then should know that we're already in proper range for DMA and no need to touch the regulator. --mtx
[PATCH] include: platform_device: add pdev_info(), pdev_warn, ... convencience macros
--- include/linux/platform_device.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 98c2a7c7108e..723c209d3760 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -368,4 +368,11 @@ extern int platform_pm_restore(struct device *dev); #define USE_PLATFORM_PM_SLEEP_OPS #endif +#define pdev_crit(pdev, fmt, args...) dev_crit(>dev, fmt, ##args) +#define pdev_err(pdev, fmt, args...) dev_err(>dev, fmt, ##args) +#define pdev_warn(pdev, fmt, args...) dev_warn(>dev, fmt, ##args) +#define pdev_notice(pdev, fmt, args...)dev_notice(>dev, fmt, ##args) +#define pdev_info(pdev, fmt, args...) dev_info(>dev, fmt, ##args) +#define pdev_debug(pdev, fmt, args...) dev_debug(>dev, fmt, ##args) + #endif /* _PLATFORM_DEVICE_H_ */ -- 2.11.0.rc0.7.gbe5a750
gpio + separate interrupts on rising / falling
Hi folks, I've got device with some strange device that triggers two irqs via one line. Rising means buffer A filled, falling mean buffer B filled. I'd like to handle that via two separate interrupts. Is it possible to register both an rising and an falling edge irq on the same line ? --mtx
Re: Proposal: single defconfig for all ARM
On 26.10.2017 18:26, Pintu Kumar wrote: Hi, My proposal is to maintain a common base defconfig file for all ARM products and only add the additional configs in the new defconfig file. I am not sure if this is already possible. If this is possible please let us know the steps. Would cat'ing 'em together do the trick ? OTOH, we could introduce meta-options in a separate menu, that just enable the actual ones. eg: --> Select SoC type --> imx6 series --> imx6 model: imx6q, imx6dl, imx6ul, ... --> enable networking --> enable lcd display --> enable hdmi display --> enable sdma --> enable usb ... --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
dtc: imx6 warnings on unit address format errors
Hi folks,
I'm getting lots of warnings from dtc about unit address format errors:
For example in imx6q.dtsi:
ocram: sram@0090 {
The node name's address part has leading zeros which dtc doesn't like.
It doesn't seem to have a big influence (yet ?), but I'd guess this
warning is there for a reason.
Should we fix this ?
--mtx
[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] 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] 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
Re: srvfs: file system for posting open file descriptors into fs namespace
On 07.08.20 18:23, Al Viro wrote: Hi, >> This is a concept from Plan9. The main purpose is allowing applications >> "dialing" some connection, do initial handshakes (eg. authentication) >> and then publish the connection to other applications, that now can now >> make use of the already dialed connection. > > Yeah, but... Linux open() always gets a new struct file instance; I know :( > how > do you work around that? Some variant of ->atomic_open() API change? > Details, please. Proxy struct file. Yes, this adds lots of bloat :( https://github.com/metux/linux-srvfs-oot/blob/master/kernel/proxy.c I thought about some possible ugly tricks of copying over one into another, but that could easily end up in a desaster. Another idea would be adding a new fs-op that returns it's own struct file - basically kinda per-fs open() syscall - which is called instead of .open, if defined. But for now, I tried to implement it as oot-module (and submit for mainline later), so it could also be used on existing distro kernels. Maybe that's not the best idea at all :o What'd be your suggestion ? --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: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces
n the isolated namespace they spawned. Don't we already have this if this user is mapped as root inside the container ? >The first consensus reached seemed to be to decouple isolated user >namespaces from shiftfs. The idea is to solely rely on tmpfs and fuse >at the beginning as filesystems which can be mounted inside isolated >user namespaces and so would have proper ownership. So, I'd essentially have to run the whole rootfs through fuse and a userland fileserver, which probably has to track things like ownerships in its own db (when running under unprivileged user) ? > For mount points >that originate from outside the namespace, everything will show as >the overflow ids and access would be restricted to the most >restricted permission bit for any path that can be accessed. So, I can't just take a btrfs snapshot as rootfs anymore ? --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: [Q] devicetree overlays
On 07.08.20 16:17, Sven Van Asbroeck wrote: Hi, > I believe you're asking: "how do I associate device tree nodes to > devices on a dynamically discoverable bus such as USB or PCI" right ? > > I believe that already exists. You can describe the _expected_ pci or > usb topology in the > devicetree. If a device gets detected in a spot on the bus described > in the tree, that > snippet will be automatically associated with this device. > > How to for usb: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/usb/usb-device.txt?h=v5.8 > > How to for pci: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci.txt?h=v5.8 Thanks, that looks good. But I've still got another problem: how can I use DT along w/ ACPI ? The scenario goes like this: * machine boots and probes normally w/ ACPI * device is detected via USB, PCI, DMI, etc -> driver gets active * driver loads (or carries) a DT snippet * devices on the bus are instantiated via this DT snippet (driver could also be some udev vodoo) Example a: * generic usb i2c dongle w/ some i2c devices attached behind it * config (or DT snippet) somewhere in the FS Example b: * x86 board driver (eg. apu2/3/4), probed via DMI * just instantiates a bunch of generic drivers and wires up devices (gpio, leds, keys, ...) Do you think we can already do that ? Otherwise, what has to be done to achieve 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 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: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling
On 08.12.20 15:19, Andy Shevchenko wrote: Hi, > Have you able to test them all? Not yet. It's still an *RFC*, I just like to discuss whether the whole idea makes sense at all. In case we come to the consensus that we should do it, I'm going to split up the patch and rework everything more carefully (for now, it's just a draft for illustrating the general idea) I'd also like to hear your opinion on whether we can consolidate these things even more, eg. using struct gpio_chip's irq data (enabled by CONFIG_GPIOLIB_IRQCHIP) instead of own fields. An interesting question here is how to do that w/o gpiolib assuming they've been managed by it - for example gpiochip_remove (which cleans up the IRQ stuff) is called by gpiochip_remove(), so we have to make sure that the driver clears the corresponding fields before gpiochip_remove() is called. So far so good. BUT: gpiochip_remove() is also called in error paths, when registration fails in the middle, and there the driver cannot act properly. Maybe introduce a flag for telling gpiolib that it should leave these fields alone and let the driver do everything ? > As the PCA953x case showed us this is not so simple, Can you tell me more about it ? (BTW haven't touched it in my patch) > besides the name > which sucks — we don't *raise* and IRQ we *handle* it. right, the naming was bad, forgot to correct that before sending. --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] RFC: drivers: gpio: helper for generic pin IRQ handling
On 08.12.20 17:18, Grygorii Strashko wrote: >>>> Having all GPIO drivers doing their IRQ management entirely through the >>>> GPIO subsystem (eg. never calling generic_handle_irq() and using the >>>> builtin >>>> IRQ handling) would also allow a more direct (eg. callback-based) >>>> pin change >>>> notification for GPIO consumers, that doesn't involve registering >>>> them as >>>> generic IRQ handlers. > > Above part makes me worry - why? Why so ? Little clarification, in case i've been a bit confusion - there're two separate topics: a) consolidating repeated patterns (eg. calling the actual irq handling) into gpiolib, (and later possibly use more fields already existing in struct gpio_chip for irq handling) b) a direct consumer callback for change, where the consumer doesn't have to care about IRQs at all (some drivers could even do polling, when hw doesn't have IRQs). This is for consumers that don't use GPIOs as interrupt source, but more more like a very raw serial port, eg. bitbanging of other interfaces (maybe an gpio bus type ? ;-)) The above paragraph just outlines that b) might be much easier to implement, once the suggested refactoring is done and no driver would call irq handlers directly anymore. But this hasn't much to do with the proposal itself, just an idea for future use. --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/2] drivers: gpio: add virtio-gpio guest driver
On 09.12.20 10:31, Jason Wang wrote: Hi, >> And even if some USB-HA driver is enabled, the actualy machine doesn't >> necessarily have the corresponding device. > > Ok, then select works for me. Great, so does everybody aggree on my patch ? https://lore.kernel.org/lkml/20201204131221.2827-1-i...@metux.net/ --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: arch: shall we have generic readl_be()/writel_be()/... or in_be32()/out_be32() ?
Hello folks, while trying to make some more drivers compile-test'able, i've discovered some arch specific calls in here, eg.: In file included from /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci-spear.c:23: /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h: In function 'ehci_readl': /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h:743:3: error: implicit declaration of function 'readl_be'; did you mean 'readsb'? [-Werror=implicit-function-declaration] 743 | readl_be(regs) : | ^~~~ | readsb /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h: In function 'ehci_writel': /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h:767:3: error: implicit declaration of function 'writel_be'; did you mean 'writesb'? [-Werror=implicit-function-declaration] 767 | writel_be(val, regs) : | ^ | writesb In file included from /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci-hcd.c:97: /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h: In function 'ehci_readl': /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h:743:3: error: implicit declaration of function 'readl_be'; did you mean 'readsb'? [-Werror=implicit-function-declaration] 743 | readl_be(regs) : | ^~~~ | readsb /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h: In function 'ehci_writel': /home/nekrad/src/apu2-dev/pkg/kernel.apu2.git/drivers/usb/host/ehci.h:767:3: error: implicit declaration of function 'writel_be'; did you mean 'writesb'? [-Werror=implicit-function-declaration] 767 | writel_be(val, regs) : | ^ | writesb It seems that only few archs (microblaze, ppc, sparc) define them. Also drivers/usb/host/ehci.h defines them, but only for one particular arch/subarch. IIRC, these funcs are for accessing hw registers that are in BEs, so BE cpus can do direct access, while LE cpus need to do a conversion. OTOH, we also have in_be32() / out_be32. They seem to do quite the same thing, referenced much more often, but also just defined on a few archs. I believe we should have generic functions, that all archs implement (possibly doing automatic conversion, if necessary), which are used by everybody else. What's your oppionion on that ? thanks, --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] drivers: usb: gadget: prefer pr_*() functions over raw printk()
On 08.12.20 16:54, Laurent Pinchart wrote:
Hi,
>> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> index 2b893bceea45..4834fafb3f70 100644
>> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> @@ -1573,7 +1573,7 @@ static void usba_control_irq(struct usba_udc *udc,
>> struct usba_ep *ep)
>> * generate or receive a reply right away. */
>> usba_ep_writel(ep, CLR_STA, USBA_RX_SETUP);
>>
>> -/* printk(KERN_DEBUG "setup: %d: %02x.%02x\n",
>> +/* pr_debug("setup: %d: %02x.%02x\n",
>> ep->state, crq.crq.bRequestType,
>> crq.crq.bRequest); */
>
> I wonder if this shouldn't be dropped instead, commented-out code isn't
> very useful.
Indeed. Shall I send a separate patch for that ?
> When a pointer to a struct device is available, dev_err() would be much
> better. That's however out of scope for this patch, but it would be nice
> to address it. This would become
>
> dev_err(>dev, "Check IRQ setup!\n");
>
You're right. I didn't check for that yet. I'll do it in a separate
patch.
--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] drivers: usb: gadget: prefer pr_*() functions over raw printk()
On 09.12.20 12:27, Laurent Pinchart wrote: Hi, >>> I wonder if this shouldn't be dropped instead, commented-out code isn't >>> very useful. >> >> Indeed. Shall I send a separate patch for that ? > > Yes, that would make sense. Okay, I'm currently doing a more in-depth rework. I'll send another patch queue later. Since I don't own the corresponding devices, I can't do much testing (just build tests and careful review), so I need some help w/ that. > As most of the files touched by this patch are device drivers, dev_*() > functions should be used instead of pr_*() where possible. I'd recommend > a first patch that converts to dev_*(), and then a second patch that > converts the remaining printk()s, if any, to pr_*() in the contexts > where no struct device is available or can easily be made available. I'm now splitting it into per-driver patches. They're getting a bit bigger, since I'm also replacing some debug macros, etc. In some cases I'm introducing new helpers for not having to write long expressions to get the actual dev ptr, adding some prefixes (eg. per usb endpoint logging, ...). --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();
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
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
[PATCH] kernel: irq: irqdesc: comments on endif's
For better readability, add a comments to #endif's, telling which condition they're closing. Signed-off-by: Enrico Weigelt, metux IT consult --- kernel/irq/irqdesc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index e810eb9906ea..ed56e9c65866 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq/irqdesc.c @@ -729,8 +729,8 @@ int handle_domain_nmi(struct irq_domain *domain, unsigned int hwirq, set_irq_regs(old_regs); return ret; } -#endif -#endif +#endif /* CONFIG_IRQ_DOMAIN */ +#endif /* CONFIG_HANDLE_DOMAIN_IRQ */ /* Dynamic interrupt handling */ -- 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 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 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 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 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 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
[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 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 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 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 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 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 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 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 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 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
