path: root/.clang-format
AgeCommit message (Collapse)AuthorLines
2019-08-31clang-format: Update with the latest for_each macro listMiguel Ojeda-3/+14
Re-run the shell fragment that generated the original list. Signed-off-by: Miguel Ojeda <>
2019-04-17Merge git:// S. Miller-0/+24
Conflict resolution of af_smc.c from Stephen Rothwell. Signed-off-by: David S. Miller <>
2019-04-12clang-format: Update with the latest for_each macro listMiguel Ojeda-0/+24
Re-run the shell fragment that generated the original list now that there are two dozens of new entries after v5.1's merge window. Signed-off-by: Miguel Ojeda <>
2019-03-21rhashtable: rename rht_for_each*continue as *from.NeilBrown-4/+4
The pattern set by list.h is that for_each..continue() iterators start at the next entry after the given one, while for_each..from() iterators start at the given entry. The rht_for_each*continue() iterators are documented as though the start at the 'next' entry, but actually start at the given entry, and they are used expecting that behaviour. So fix the documentation and change the names to *from for consistency with list.h Acked-by: Herbert Xu <> Acked-by: Miguel Ojeda <> Signed-off-by: NeilBrown <> Signed-off-by: David S. Miller <>
2019-03-12Merge branch 'work.iov_iter' of ↵Linus Torvalds-1/+0
git:// Pull iov_iter updates from Al Viro: "A couple of iov_iter patches - Christoph's crapectomy (the last remaining user of iov_for_each() went away with lustre, IIRC) and Eric'c optimization of sanity checks" * 'work.iov_iter' of git:// iov_iter: optimize page_copy_sane() uio: remove the unused iov_for_each macro
2019-02-19RDMA: Add and use rdma_for_each_portJason Gunthorpe-0/+1
We have many loops iterating over all of the end port numbers on a struct ib_device, simplify them with a for_each helper. Reviewed-by: Parav Pandit <> Signed-off-by: Jason Gunthorpe <>
2019-02-11lib/scatterlist: Provide a DMA page iteratorJason Gunthorpe-0/+1
Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o backing pages") introduced the sg_page_iter_dma_address() function without providing a way to use it in the general case. If the sg_dma_len() is not equal to the sg length callers cannot safely use the for_each_sg_page/sg_page_iter_dma_address combination. Resolve this API mistake by providing a DMA specific iterator, for_each_sg_dma_page(), that uses the right length so sg_page_iter_dma_address() works as expected with all sglists. A new iterator type is introduced to provide compile-time safety against wrongly mixing accessors and iterators. Acked-by: Christoph Hellwig <> (for scatterlist) Acked-by: Thomas Hellstrom <> Acked-by: Sakari Ailus <> (ipu3-cio2) Signed-off-by: Jason Gunthorpe <>
2019-02-04uio: remove the unused iov_for_each macroChristoph Hellwig-1/+0
Signed-off-by: Christoph Hellwig <> Signed-off-by: Al Viro <>
2019-01-19clang-format: Update .clang-format with the latest for_each macro listJason Gunthorpe-1/+42
Re-run the shell fragment that generated the original list. In particular this adds the missing xarray related functions. Signed-off-by: Jason Gunthorpe <> Signed-off-by: Miguel Ojeda <>
2018-10-21page cache: Convert find_get_pages_contig to XArrayMatthew Wilcox-1/+0
There's no direct replacement for radix_tree_for_each_contig() in the XArray API as it's an unusual thing to do. Instead, open-code a loop using xas_next(). This removes the only user of radix_tree_for_each_contig() so delete the iterator from the API and the test suite code for it. Signed-off-by: Matthew Wilcox <>
2018-08-01clang-format: Set IndentWrappedFunctionNames falseJason Gunthorpe-1/+1
The true option causes this indenting for functions: static struct something_very_very_long * function(void *arg) { While a quick survey suggests that the usual Linux fallback is the GNU style: static struct something_very_very_long * function(void *arg) { Eg as seen in: kernel/cpu.c kernel/fork.c etc Acked-by: Joe Perches <> Signed-off-by: Jason Gunthorpe <> Signed-off-by: Miguel Ojeda <>
2018-04-11clang-format: add configuration fileMiguel Ojeda-0/+428
clang-format is a tool to format C/C++/... code according to a set of rules and heuristics. Like most tools, it is not perfect nor covers every single case, but it is good enough to be helpful. In particular, it is useful for quickly re-formatting blocks of code automatically, for reviewing full files in order to spot coding style mistakes, typos and possible improvements. It is also handy for sorting ``#includes``, for aligning variables and macros, for reflowing text and other similar tasks. It also serves as a teaching tool/guide for newcomers. The tool itself has been already included in the repositories of popular Linux distributions for a long time. The rules in this file are intended for clang-format >= 4, which is easily available in most distributions. This commit adds the configuration file that contains the rules that the tool uses to know how to format the code according to the kernel coding style. This gives us several advantages: * clang-format works out of the box with reasonable defaults; avoiding that everyone has to re-do the configuration. * Everyone agrees (eventually) on what is the most useful default configuration for most of the kernel. * If it becomes commonplace among kernel developers, clang-format may feel compelled to support us better. They already recognize the Linux kernel and its style in their documentation and in one of the style sub-options. Some of clang-format's features relevant for the kernel are: * Uses clang's tooling support behind the scenes to parse and rewrite the code. It is not based on ad-hoc regexps. * Supports reasonably well the Linux kernel coding style. * Fast enough to be used at the press of a key. * There are already integrations (either built-in or third-party) for many common editors used by kernel developers (e.g. vim, emacs, Sublime, Atom...) that allow you to format an entire file or, more usefully, just your selection. * Able to parse unified diffs -- you can, for instance, reformat only the lines changed by a git commit. * Able to reflow text comments as well. * Widely supported and used by hundreds of developers in highly complex projects and organizations (e.g. the LLVM project itself, Chromium, WebKit, Google, Mozilla...). Therefore, it will be supported for a long time. See more information about the tool at: Link: Signed-off-by: Miguel Ojeda <> Cc: Randy Dunlap <> Cc: Andy Whitcroft <> Cc: Joe Perches <> Cc: Jonathan Corbet <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>