- Jul 17, 2019
-
-
Masahiro Yamada authored
The assembler files in the kernel are *.S instead of *.s, so they must be preprocessed. Since 'as' of GNU binutils is not able to preprocess, we always use $(CC) as an assembler driver. $(AS) is almost unused in Kbuild. As of v5.2, there is just one place that directly invokes $(AS). $ git grep -e '$(AS)' -e '${AS}' -e '$AS' -e '$(AS:' -e '${AS:' -- :^Documentation drivers/net/wan/Makefile: AS68K = $(AS) The documentation about *_AFLAGS* sounds like the flags were passed to $(AS). This is somewhat misleading. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com>
-
- Jul 12, 2019
-
-
Luigi Semenzato authored
Report separate components (anon, file, and shmem) for PSS in smaps_rollup. This helps understand and tune the memory manager behavior in consumer devices, particularly mobile devices. Many of them (e.g. chromebooks and Android-based devices) use zram for anon memory, and perform disk reads for discarded file pages. The difference in latency is large (e.g. reading a single page from SSD is 30 times slower than decompressing a zram page on one popular device), thus it is useful to know how much of the PSS is anon vs. file. All the information is already present in /proc/pid/smaps, but much more expensive to obtain because of the large size of that procfs entry. This patch also removes a small code duplication in smaps_account, which would have gotten worse otherwise. Also updated Documentation/filesystems/proc.txt (the smaps section was a bit stale, and I added a smaps_rollup section) and Documentation/ABI/testing/procfs-smaps_rollup. [semenzato@chromium.org: v5] Link: http://lkml.kernel.org/r/20190626234333.44608-1-semenzato@chromium.org Link: http://lkml.kernel.org/r/20190626180429.174569-1-semenzato@chromium.org Signed-off-by:
Luigi Semenzato <semenzato@chromium.org> Acked-by:
Yu Zhao <yuzhao@chromium.org> Cc: Sonny Rao <sonnyrao@chromium.org> Cc: Yu Zhao <yuzhao@chromium.org> Cc: Brian Geffon <bgeffon@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Alexander Potapenko authored
Patch series "add init_on_alloc/init_on_free boot options", v10. Provide init_on_alloc and init_on_free boot options. These are aimed at preventing possible information leaks and making the control-flow bugs that depend on uninitialized values more deterministic. Enabling either of the options guarantees that the memory returned by the page allocator and SL[AU]B is initialized with zeroes. SLOB allocator isn't supported at the moment, as its emulation of kmem caches complicates handling of SLAB_TYPESAFE_BY_RCU caches correctly. Enabling init_on_free also guarantees that pages and heap objects are initialized right after they're freed, so it won't be possible to access stale data by using a dangling pointer. As suggested by Michal Hocko, right now we don't let the heap users to disable initialization for certain allocations. There's not enough evidence that doing so can speed up real-life cases, and introducing ways to opt-out may result in things going out of control. This patch (of 2): The new options are needed to prevent possible information leaks and make control-flow bugs that depend on uninitialized values more deterministic. This is expected to be on-by-default on Android and Chrome OS. And it gives the opportunity for anyone else to use it under distros too via the boot args. (The init_on_free feature is regularly requested by folks where memory forensics is included in their threat models.) init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes. Initialization is done at allocation time at the places where checks for __GFP_ZERO are performed. init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn't leak via use-after-free accesses. Both init_on_alloc=1 and init_on_free=1 guarantee that the allocator returns zeroed memory. The two exceptions are slab caches with constructors and SLAB_TYPESAFE_BY_RCU flag. Those are never zero-initialized to preserve their semantics. Both init_on_alloc and init_on_free default to zero, but those defaults can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON. If either SLUB poisoning or page poisoning is enabled, those options take precedence over init_on_alloc and init_on_free: initialization is only applied to unpoisoned allocations. Slowdown for the new features compared to init_on_free=0, init_on_alloc=0: hackbench, init_on_free=1: +7.62% sys time (st.err 0.74%) hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%) Linux build with -j12, init_on_free=1: +8.38% wall time (st.err 0.39%) Linux build with -j12, init_on_free=1: +24.42% sys time (st.err 0.52%) Linux build with -j12, init_on_alloc=1: -0.13% wall time (st.err 0.42%) Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%) The slowdown for init_on_free=0, init_on_alloc=0 compared to the baseline is within the standard error. The new features are also going to pave the way for hardware memory tagging (e.g. arm64's MTE), which will require both on_alloc and on_free hooks to set the tags for heap objects. With MTE, tagging will have the same cost as memory initialization. Although init_on_free is rather costly, there are paranoid use-cases where in-memory data lifetime is desired to be minimized. There are various arguments for/against the realism of the associated threat models, but given that we'll need the infrastructure for MTE anyway, and there are people who want wipe-on-free behavior no matter what the performance cost, it seems reasonable to include it in this series. [glider@google.com: v8] Link: http://lkml.kernel.org/r/20190626121943.131390-2-glider@google.com [glider@google.com: v9] Link: http://lkml.kernel.org/r/20190627130316.254309-2-glider@google.com [glider@google.com: v10] Link: http://lkml.kernel.org/r/20190628093131.199499-2-glider@google.com Link: http://lkml.kernel.org/r/20190617151050.92663-2-glider@google.com Signed-off-by:
Alexander Potapenko <glider@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by: Michal Hocko <mhocko@suse.cz> [page and dmapool parts Acked-by:
James Morris <jamorris@linux.microsoft.com>]> Cc: Christoph Lameter <cl@linux.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Sandeep Patil <sspatil@android.com> Cc: Laura Abbott <labbott@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Jann Horn <jannh@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marco Elver <elver@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Shakeel Butt authored
The memory controller in cgroup v2 exposes memory.events file for each memcg which shows the number of times events like low, high, max, oom and oom_kill have happened for the whole tree rooted at that memcg. Users can also poll or register notification to monitor the changes in that file. Any event at any level of the tree rooted at memcg will notify all the listeners along the path till root_mem_cgroup. There are existing users which depend on this behavior. However there are users which are only interested in the events happening at a specific level of the memcg tree and not in the events in the underlying tree rooted at that memcg. One such use-case is a centralized resource monitor which can dynamically adjust the limits of the jobs running on a system. The jobs can create their sub-hierarchy for their own sub-tasks. The centralized monitor is only interested in the events at the top level memcgs of the jobs as it can then act and adjust the limits of the jobs. Using the current memory.events for such centralized monitor is very inconvenient. The monitor will keep receiving events which it is not interested and to find if the received event is interesting, it has to read memory.event files of the next level and compare it with the top level one. So, let's introduce memory.events.local to the memcg which shows and notify for the events at the memcg level. Now, does memory.stat and memory.pressure need their local versions. IMHO no due to the no internal process contraint of the cgroup v2. The memory.stat file of the top level memcg of a job shows the stats and vmevents of the whole tree. The local stats or vmevents of the top level memcg will only change if there is a process running in that memcg but v2 does not allow that. Similarly for memory.pressure there will not be any process in the internal nodes and thus no chance of local pressure. Link: http://lkml.kernel.org/r/20190527174643.209172-1-shakeelb@google.com Signed-off-by:
Shakeel Butt <shakeelb@google.com> Reviewed-by:
Roman Gushchin <guro@fb.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Chris Down <chris@chrisdown.name> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Vlastimil Babka authored
When debug_pagealloc is enabled, we currently allocate the page_ext array to mark guard pages with the PAGE_EXT_DEBUG_GUARD flag. Now that we have the page_type field in struct page, we can use that instead, as guard pages are neither PageSlab nor mapped to userspace. This reduces memory overhead when debug_pagealloc is enabled and there are no other features requiring the page_ext array. Link: http://lkml.kernel.org/r/20190603143451.27353-4-vbabka@suse.cz Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Marco Elver authored
This adds a new header to asm-generic to allow optionally instrumenting architecture-specific asm implementations of bitops. This change includes the required change for x86 as reference and changes the kernel API doc to point to bitops-instrumented.h instead. Rationale: the functions in x86's bitops.h are no longer the kernel API functions, but instead the arch_ prefixed functions, which are then instrumented via bitops-instrumented.h. Other architectures can similarly add support for asm implementations of bitops. The documentation text was derived from x86 and existing bitops asm-generic versions: 1) references to x86 have been removed; 2) as a result, some of the text had to be reworded for clarity and consistency. Tested using lib/test_kasan with bitops tests (pre-requisite patch). Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=198439 Link: http://lkml.kernel.org/r/20190613125950.197667-4-elver@google.com Signed-off-by:
Marco Elver <elver@google.com> Acked-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
André Almeida authored
Wikipedia now has a main article to "tracing garbage collector" topic. Change the URL and use the reStructuredText syntax for hyperlinks and add more details about the use of the tool. Add a section about how to use the kmemleak-test module to test the memory leak scanning. Link: http://lkml.kernel.org/r/20190612155231.19448-2-andrealmeid@collabora.com Signed-off-by:
André Almeida <andrealmeid@collabora.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Mike Snitzer authored
discard_zeroes_cow - a discard issued to the snapshot device that maps to entire chunks to will zero the corresponding exception(s) in the snapshot's exception store. discard_passdown_origin - a discard to the snapshot device is passed down to the snapshot-origin's underlying device. This doesn't cause copy-out to the snapshot exception store because the snapshot-origin target is bypassed. The discard_passdown_origin feature depends on the discard_zeroes_cow feature being enabled. When these 2 features are enabled they allow a temporarily read-only device that has completely exhausted its free space to recover space. To do so dm-snapshot provides temporary buffer to accommodate writes that the temporarily read-only device cannot handle yet. Once the upper layer frees space (e.g. fstrim to XFS) the discards issued to the dm-snapshot target will be issued to underlying read-only device whose free space was exhausted. In addition those discards will also cause zeroes to be written to the snapshot exception store if corresponding exceptions exist. If the underlying origin device provides deduplication for zero blocks then if/when the snapshot is merged backed to the origin those blocks will become unused. Once the origin has gained adequate space, merging the snapshot back to the thinly provisioned device will permit continued use of that device without the temporary space provided by the snapshot. Requested-by:
John Dorminy <jdorminy@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com>
-
- Jul 11, 2019
-
-
Luke Nowakowski-Krijger authored
Added toctree hooks for indexing. Hooks added only for newly added files. The hook for the top of the tree will be added in a later patch series when a few more substantial changes have been added. Signed-off-by:
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Luke Nowakowski-Krijger authored
Convert cpuid.txt to .rst format to be parsable by sphinx. Change format and spacing to make function definitions and return values much more clear. Also added a table that is parsable by sphinx and makes the information much more clean. Updated Author email to their new active email address. Added license identifier with the consent of the author. Signed-off-by:
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Luke Nowakowski-Krijger authored
Convert paravirt_opts.txt to .rst format to be able to be parsed by sphinx. Made some minor spacing and formatting corrections to make defintions much more clear and easy to read. Added default kernel license to the document. Signed-off-by:
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Eric Hankland authored
Some events can provide a guest with information about other guests or the host (e.g. L3 cache stats); providing the capability to restrict access to a "safe" set of events would limit the potential for the PMU to be used in any side channel attacks. This change introduces a new VM ioctl that sets an event filter. If the guest attempts to program a counter for any blacklisted or non-whitelisted event, the kernel counter won't be created, so any RDPMC/RDMSR will show 0 instances of that event. Signed-off-by:
Eric Hankland <ehankland@google.com> [Lots of changes. All remaining bugs are probably mine. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Suman Anna authored
The TI K3 AM65x and J721E family of SoCs have a new Mailbox IP that is based on the existing Mailbox IP present in OMAP architecture based SoCs. Update the existing OMAP Mailbox bindings for this new IP present on TI K3 AM65x and J721E SoCs. The same compatible from AM65x SoCs is reused for J721E SoCs. Signed-off-by:
Suman Anna <s-anna@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org>
-
Linus Torvalds authored
Revert "Merge tag 'keys-acl-20190703' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs" This reverts merge 0f75ef6a (and thus effectively commits 7a1ade84 ("keys: Provide KEYCTL_GRANT_PERMISSION") 2e12256b ("keys: Replace uid/gid/perm permissions checking with an ACL") that the merge brought in). It turns out that it breaks booting with an encrypted volume, and Eric biggers reports that it also breaks the fscrypt tests [1] and loading of in-kernel X.509 certificates [2]. The root cause of all the breakage is likely the same, but David Howells is off email so rather than try to work it out it's getting reverted in order to not impact the rest of the merge window. [1] https://lore.kernel.org/lkml/20190710011559.GA7973@sol.localdomain/ [2] https://lore.kernel.org/lkml/20190710013225.GB7973@sol.localdomain/ Link: https://lore.kernel.org/lkml/CAHk-=wjxoeMJfeBahnWH=9zShKp2bsVy527vo3_y8HfOdhwAAw@mail.gmail.com/ Reported-by:
Eric Biggers <ebiggers@kernel.org> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jul 10, 2019
-
-
Damien Le Moal authored
The ELV_MQUEUE_XXX definitions in include/linux/elevator.h are unused since the removal of elevator_may_queue_fn in kernel 5.0. Remove these definitions and also remove the documentation of elevator_may_queue_fn in Documentiation/block/biodoc.txt. Acked-by:
Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Masahiro Yamada authored
In old days, Kbuild always used an absolute path for $(srctree). Since commit 890676c6 ("kbuild: Use relative path when building in the source tree"), $(srctree) is '.' when O= was not passed from the command line. Yet, using absolute paths is useful in some cases even without O=, for instance, to create a cscope file with absolute path tags. 'O=.' was known to work as a workaround to force Kbuild to use absolute paths even when you are building in the source tree. Since commit 25b146c5 ("kbuild: allow Kbuild to start from any directory"), Kbuild is too clever to be tricked. Even if you pass 'O=.' Kbuild notices you are building in the source tree, then use '.' for $(srctree). So, 'make O=. cscope' is no help to create absolute path tags. We cannot force one or the other according to commit e93bc1a0 ("Revert "kbuild: specify absolute paths for cscope""). Both of relative path and absolute path have pros and cons. This commit adds a new flag KBUILD_ABS_SRCTREE to allow users to choose the absolute path for $(srctree). 'make KBUILD_ABS_SRCTREE=1 cscope' will work as a replacement of 'make O=. cscope'. Reported-by:
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Tejun Heo authored
wbc_account_io() does a very specific job - try to see which cgroup is actually dirtying an inode and transfer its ownership to the majority dirtier if needed. The name is too generic and confusing. Let's rename it to something more specific. Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Masahiro Yamada authored
As commit b6147490 ("mmc: tmio: split core functionality, DMA and MFD glue") said, these MMC controllers use the IP from Panasonic. TMIO (Toshiba Mobile IO) MMC was the first upstreamed user of this IP. The common driver code was split and expanded as 'tmio-mmc-core', then it became historical misnomer since 'tmio' is not the name of this IP. In the discussion [1], we decide to keep this name as-is at least in Linux driver level because renaming everything is a big churn. However, DT should not be oriented to a particular project even though it is mainly developed in Linux communities. This is the misfortune only in Linux. Let's stop exporting it to other projects, where there is no good reason to call this hardware "TMIO". Rename the file to renesas,sdhi.txt. In fact, all the information in this file is specific to the Renesas platform. This commit also removes the first paragraph entirely. The DT-binding should describe the hardware. It is strange to talk about Linux driver internals such as how the drivers are probed, how platform data are handed off, etc. [1] https://www.spinics.net/lists/linux-mmc/msg46952.html Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Baolin Wang authored
When changing SD card voltage signal for Spreadtrum SD host controller, it also need to switch related pin's state. Thus add pinctrl properties' description in documentation. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
- Jul 09, 2019
-
-
Icenowy Zheng authored
Shenzhen Sipeed Technology Co., Ltd. is a company focused on development kits, which also contains rebranded Lichee Pi series. Add its vendor prefix binding. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Icenowy Zheng authored
Shenzhen SoChip Technology Co., Ltd. is a hardware vendor that produces EVBs with Allwinner chips. There's also a SoC named S3 that is developed by Allwinner (based on Allwinner V3/V3s) but branded SoChip. Add the vendor prefix for SoChip. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Kefeng Wang authored
28eac2b7 ("powerpc/fsl: Remove cell-index from PCI nodes"), and for now it is still not used, drop it from doc. Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Jiangfeng Xiao authored
In general, group is the same as the port, but some boards specify a special group for better load balancing of each processing unit. Signed-off-by:
Jiangfeng Xiao <xiaojiangfeng@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Claire Chang authored
To support Rx in-band wakeup, one must create an interrupt specifier with edge sensitivity on Rx pin and an addtional pinctrl to reconfigure Rx pin to normal GPIO in sleep state. Driver will switch to sleep mode pinctrl and enable irq wake before suspend and restore to default settings when resuming. Signed-off-by:
Claire Chang <tientzu@chromium.org> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Josua Mayer authored
Armada 8040 needs four clocks to be enabled for MDIO accesses to work. Update the binding to allow the extra clock to be specified. Cc: stable@vger.kernel.org Fixes: 6d6a331f ("dt-bindings: allow up to three clocks for orion-mdio") Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Josua Mayer <josua@solid-run.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Rob Herring authored
Convert RDA Micro SoC bindings to DT schema format using json-schema. Cc: "Andreas Färber" <afaerber@suse.de> Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Masahiro Yamada authored
In my view, most of headers can be self-contained. So, it would be tedious to add every header to header-test-y explicitly. We usually end up with "all headers with some exceptions". There are two types in exceptions: [1] headers that are never compiled as standalone units For examples, include/linux/compiler-gcc.h is not intended for direct inclusion. We should always exclude such ones. [2] headers that are conditionally compiled as standalone units Some headers can be compiled only for particular architectures. For example, include/linux/arm-cci.h can be compiled only for arm/arm64 because it requires <asm/arm-cci.h> to exist. Clang can compile include/soc/nps/mtm.h only for arc because it contains an arch-specific register in inline assembler. So, you can write Makefile like this: header-test- += linux/compiler-gcc.h header-test-$(CONFIG_ARM) += linux/arm-cci.h header-test-$(CONFIG_ARM64) += linux/arm-cci.h header-test-$(CONFIG_ARC) += soc/nps/mtm.h The new syntax header-test-pattern-y will be useful to specify "the rest". The typical usage is like this: header-test-pattern-y += */*.h This will add all the headers in sub-directories to the test coverage, excluding $(header-test-). In this regards, header-test-pattern-y behaves like a weaker variant of header-test-y. Caveat: The patterns in header-test-pattern-y are prefixed with $(srctree)/$(src)/ but not $(objtree)/$(obj)/. Stale generated headers are often left over when you traverse the git history without cleaning. Wildcard patterns for $(objtree) may match to stale headers, which could fail to compile. One pitfall is $(srctree)/$(src)/ and $(objtree)/$(obj)/ point to the same directory for in-tree building. So, header-test-pattern-y should be used with care since it can potentially match to stale headers. Caveat2: You could use wildcard for header-test-. For example, header-test- += asm-generic/% ... will exclude headers in asm-generic directory. Unfortunately, the wildcard character is '%' instead of '*' here because this is evaluated by $(filter-out ...) whereas header-test-pattern-y is evaluated by $(wildcard ...). This is a kludge, but seems useful in some places... Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by:
Jani Nikula <jani.nikula@intel.com>
-
Masahiro Yamada authored
header-test-y does not work with headers in sub-directories. For example, you may want to write a Makefile, like this: include/linux/Kbuild: header-test-y += mtd/nand.h This entry will create a wrapper include/linux/mtd/nand.hdrtest.c with the following content: #include "mtd/nand.h" To make this work, we need to add $(srctree)/include/linux to the header search path. It would be tedious to add ccflags-y. Instead, we could change the *.hdrtest.c rule to wrap: #include "nand.h" This works for in-tree build since #include "..." searches in the relative path from the header with this directive. For O=... build, we need to add $(srctree)/include/linux/mtd to the header search path, which will be even more tedious. After all, I thought it would be handier to compile headers directly without creating wrappers. I added a new build rule to compile %.h into %.h.s The target is %.h.s instead of %.h.o because it is slightly faster. Also, as for GCC, an empty assembly is smaller than an empty object. I wrote the build rule: $(CC) $(c_flags) -S -o $@ -x c /dev/null -include $< instead of: $(CC) $(c_flags) -S -o $@ -x c $< Both work fine with GCC, but the latter is bad for Clang. This comes down to the difference in the -Wunused-function policy. GCC does not warn about unused 'static inline' functions at all. Clang does not warn about the ones in included headers, but does about the ones in the source. So, we should handle headers as headers, not as source files. In fact, this has been hidden since commit abb2ea7d ("compiler, clang: suppress warning for unused static inline functions"), but we should not rely on that. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Jani Nikula <jani.nikula@intel.com>
-
- Jul 08, 2019
-
-
Stephen Suryaputra authored
Make the same support as commit 363887a2 ("ipv4: Support multipath hashing on inner IP pkts for GRE tunnel") for outer IPv6. The hashing considers both IPv4 and IPv6 pkts when they are tunneled by IPv6 GRE. Signed-off-by:
Stephen Suryaputra <ssuryaextr@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Benedikt Spranger authored
Document the different needs of documentation for the b53 driver. Signed-off-by:
Benedikt Spranger <b.spranger@linutronix.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Benedikt Spranger authored
Document DSA tagged and VLAN based switch configuration by showcases. Signed-off-by:
Benedikt Spranger <b.spranger@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mauro Carvalho Chehab authored
When using the automarkup extension with: make pdfdocs without passing an specific book, the code will raise an exception: File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 86, in auto_markup node.parent.replace(node, markup_funcs(name, app, node)) File "/devel/v4l/docs/Documentation/sphinx/automarkup.py", line 59, in markup_funcs 'function', target, pxref, lit_text) File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/domains/c.py", line 308, in resolve_xref contnode, target) File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/util/nodes.py", line 450, in make_refnode '#' + targetid) File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 159, in get_relative_uri return self.get_target_uri(to, typ) File "/devel/v4l/docs/sphinx_2.0/lib/python3.7/site-packages/sphinx/builders/latex/__init__.py", line 152, in get_target_uri raise NoUri sphinx.environment.NoUri This happens because not all references will belong to a single PDF/LaTeX document. Better to just ignore those than breaking Sphinx build. Fixes: d74b0d31 ("Docs: An initial automarkup extension for sphinx") Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> [jc: Narrowed the "except" and tweaked the comment] Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Matthew Wilcox (Oracle) authored
The documentation is more appropriate for the administrator than for the internal kernel API section it is currently in. Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by:
Christian Brauner <christian@brauner.io> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Mauro Carvalho Chehab authored
While this contains some uAPI stuff, it was intended to be read by a kernel doc. So, let's not move it to a different dir, but, instead, just add it to the driver-api bookset. Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
Hou Zhiqiang authored
Change the "gpio_slave" and "apb_csr" to optional, the "gpio_slave" is not used in current code, and "apb_csr" is not used by some platforms. Signed-off-by:
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Minghuan Lian <Minghuan.Lian@nxp.com> Reviewed-by:
Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
-
- Jul 07, 2019
-
-
Pawel Dembicki authored
This commit introduce how to use vsc73xx platform driver. Signed-off-by:
Pawel Dembicki <paweldembicki@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Jul 06, 2019
-
-
Sean Wang authored
Some board requires explicitily control external osscilator via GPIO. So, add a clock property for an external oscillator for the device. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Sean Wang authored
Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so adding an additional boot-gpios property for such platform allows them to bring up the device. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Rocky Liao authored
This patch adds an optional device property "firmware-name" to allow the driver to load customized nvm firmware file based on this property. Signed-off-by:
Rocky Liao <rjliao@codeaurora.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Sascha Hauer authored
This adds serdev support to the Marvell hci uart driver. Only basic serdev support, none of the fancier features like regulator or enable GPIO support is added for now. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-