- 03 May, 2019 1 commit
-
-
Stephen Boyd authored
If a clk has specified parents via clk_hw pointers it won't specify the globally unique names for the parents. Without the unique names, we can't fallback to comparing them against the name of the 'parent' pointer here. Therefore, do a pointer comparison against the clk_hw pointers too and cache the clk_core structure if they match. This fixes parent lookup code for clks that only specify clk_hw pointers and nothing else, like muxes that are purely inside a clk controller. Similarly, if the parent pointer isn't cached after trying to match clk_core or clk_hw pointers, lookup the pointer from DT or via clkdev lookups instead of relying purely on the globally unique clk name match. This should allow us to move away from having to specify global names for clk parents entirely. While we're in the area, add some comments so it's clearer what's going on. The if statements don't lend themselves to much clarity in their raw form. Fixes: fc0c209c ("clk: Allow parents to be specified without string names") Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 23 Apr, 2019 1 commit
-
-
Stephen Boyd authored
This structure can be full of junk from the stack if we don't initialize it. The clk framework tests clk_init_data::parent_names for non-NULL and then considers that as the parent name pointer, but if it's full of junk then we'll try to deref a bad pointer and oops the system. Let's initialize the structure so that only clk_init_data::parent_names or clk_init_data::parent_data is set, and not both. Reported-by: "kernelci.org bot" <bot@kernelci.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Tony Lindgren <tony@atomide.com> Fixes: ecbf3f17 ("clk: fixed-factor: Let clk framework find parent") Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 19 Apr, 2019 8 commits
-
-
Stephen Boyd authored
Convert this driver to a more modern way of specifying parents now that we have a way to specify clk parents by DT index. This lets us nicely avoid a problem where a parent clk name isn't know because the parent clk hasn't been registered yet. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
Some clk providers are simple DT nodes that only have a 'clocks' property without having an associated 'clock-names' property. In these cases, we want to let these clk providers point to their parent clks without having to dereference the 'clocks' property at probe time to figure out the parent's globally unique clk name. Let's add an 'index' property to the parent_data structure so that clk providers can indicate that their parent is a particular index in the 'clocks' DT property. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
In addition to looking for DT based parents, support clkdev based clk_lookups. This should allow non-DT based clk drivers to participate in the parent lookup process. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
The common clk framework is lacking in ability to describe the clk topology without specifying strings for every possible parent-child link. There are a few drawbacks to the current approach: 1) String comparisons are used for everything, including describing topologies that are 'local' to a single clock controller. 2) clk providers (e.g. i2c clk drivers) need to create globally unique clk names to avoid collisions in the clk namespace, leading to awkward name generation code in various clk drivers. 3) DT bindings may not fully describe the clk topology and linkages between clk controllers because drivers can easily rely on globally unique strings to describe connections between clks. This leads to confusing DT bindings, complicated clk name generation code, and inefficient string comparisons during clk registration just so that the clk framework can detect the topology of the clk tree. Furthermore, some drivers call clk_get() and then __clk_get_name() to extract the globally unique clk name just so they can specify the parent of the clk they're registering. We have of_clk_parent_fill() but that mostly only works for single clks registered from a DT node, which isn't the norm. Let's simplify this all by introducing two new ways of specifying clk parents. The first method is an array of pointers to clk_hw structures corresponding to the parents at that index. This works for clks that are registered when we have access to all the clk_hw pointers for the parents. The second method is a mix of clk_hw pointers and strings of local and global parent clk names. If the .fw_name member of the map is set we'll look for that clk by performing a DT based lookup of the device the clk is registered with and the .name specified in the map. If that fails, we'll fallback to the .name member and perform a global clk name lookup like we've always done before. Using either one of these new methods is entirely optional. Existing drivers will continue to work, and they can migrate to this new approach as they see fit. Eventually, we'll want to get rid of the 'parent_names' array in struct clk_init_data and use one of these new methods instead. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Rob Herring <robh@kernel.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
In some circumstances drivers register clks early and don't have access to a struct device because the device model isn't initialized yet. Add an API to let drivers register clks associated with a struct device_node so that these drivers can participate in getting parent clks through DT. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Rob Herring <robh@kernel.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
We'd like to chain this in places where the 'dev' argument might be NULL. Let this function take a NULL 'dev' so this can work. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rob Herring <robh@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
Split out the body of the clk_register() function so it can be shared between the different types of registration APIs (DT, device). Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Rob Herring <robh@kernel.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Stephen Boyd authored
We don't need to hold the 'clocks_mutex' here when we're creating a clk pointer from a clk_lookup structure. Instead, we just need to make sure that the lookup doesn't go away while we dereference the lookup pointer to extract the clk_hw pointer out of it. Let's move things around slightly so that we have a new function to get the clk_hw out of the lookup with the right locking and then chain the two together for what used to be __clk_get_sys(). Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 18 Apr, 2019 1 commit
-
-
Stephen Boyd authored
We recently introduced a change to support devm clk lookups. That change introduced a code-path that used clk_find() without holding the 'clocks_mutex'. Unfortunately, clk_find() iterates over the 'clocks' list and so we need to prevent the list from being modified at the same time. Do this by holding the mutex and checking to make sure it's held while iterating the list. Note, we don't really care if the lookup is freed after we find it with clk_find() because we're just doing a pointer comparison, but if we did care we would need to keep holding the mutex while we dereference the clk_lookup pointer. Fixes: 3eee6c7d ("clkdev: add managed clkdev lookup registration") Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 12 Apr, 2019 2 commits
-
-
Leonard Crestez authored
Code which initializes the "clk_init_data.ops" checks pll->rate_table before that field is ever assigned to so it always picks "clk_pll1416x_min_ops". This breaks dynamic rate rounding for features such as cpufreq. Fix by checking pll_clk->rate_table instead, here pll_clk refers to the constant initialization data coming from per-soc clk driver. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Fixes: 8646d4dc ("clk: imx: Add PLLs driver for imx8mm soc") Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
Weiyi Lu authored
CLK_SET_RATE_PARENT would be dropped. Merge two flag setting together to correct the error. Fixes: 5a1cc4c2 ("clk: mediatek: Add flags to mtk_gate") Cc: <stable@vger.kernel.org> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 11 Apr, 2019 1 commit
-
-
Stephen Boyd authored
It's used by probe and that isn't an init function. Drop this so that we don't get a section mismatch. Reported-by: kbuild test robot <lkp@intel.com> Cc: David Müller <dave.mueller@gmx.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Fixes: 7c2e0713 ("clk: x86: Add system specific quirk to mark clocks as critical") Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 10 Apr, 2019 1 commit
-
-
David Müller authored
Since commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel's knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by: David Müller <dave.mueller@gmx.ch> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 29 Mar, 2019 2 commits
-
-
https://github.com/BayLibre/clk-mesonStephen Boyd authored
Pull more fixes for meson clocks from Neil Armstrong: - clk-pll: fix rate rounding fixing meson8b boot failure - vid-pll-div: fix recal_rate warning and return when invalid setting * tag 'meson-clk-fixes-for-5.1-v2' of https://github.com/BayLibre/clk-meson: clk: meson: vid-pll-div: remove warning and return 0 on invalid config clk: meson: pll: fix rounding and setting a rate that matches precisely
-
Neil Armstrong authored
The vid_pll_div is a programmable fractional divider, but vendor gives a limited of known configuration value and it's corresponding fraction. Thus when at reset value (0) or unknown value, we cannot determine the result rate. The initial behaviour was to print a warning, but the warning triggers at each boot and when the clock tree is refreshed. This patch moves the print to debug and returns 0 instead of the parent rate. Fixes: 72dbb8c9 ("clk: meson: Add vid_pll divider driver") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lkml.kernel.org/r/20190327151348.27402-1-narmstrong@baylibre.com
-
- 25 Mar, 2019 1 commit
-
-
Martin Blumenstingl authored
Make meson_clk_pll_is_better() consider a rate that precisely matches the requested rate to be better than any previous rate (which was smaller than the current). Prior to commit 8eed1db1 ("clk: meson: pll: update driver for the g12a") meson_clk_get_pll_settings() returned early (before calling meson_clk_pll_is_better()) if the rate from the current iteration matches the requested rate precisely. After this commit meson_clk_pll_is_better() is called unconditionally. This requires meson_clk_pll_is_better() to work with the case where "now == rate". This fixes a hang during boot on Meson8b / Odroid-C1 for me. Fixes: 8eed1db1 ("clk: meson: pll: update driver for the g12a") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190324164327.22590-2-martin.blumenstingl@googlemail.com
-
- 19 Mar, 2019 4 commits
-
-
https://github.com/BayLibre/clk-mesonStephen Boyd authored
Pull a round of fixes for meson clocks from Neil Armstrong: - g12a: Fix VPU clock parents and mux mask - gxbb: Add CLK_DIVIDER_ROUND_CLOSEST to video decoder clocks * tag 'meson-clk-fixes-for-5.1' of https://github.com/BayLibre/clk-meson: clk: meson-g12a: fix VPU clock parents clk: meson: g12a: fix VPU clock muxes mask clk: meson-gxbb: round the vdec dividers to closest
-
Neil Armstrong authored
First two VPU clock parents are wrong, fix it here. Fixes: 085a4ea9 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lkml.kernel.org/r/20190313135503.3198-1-narmstrong@baylibre.com
-
Maxime Jourdan authored
There are 8 parents, use 0x7 Fixes: 085a4ea9 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319082611.6215-1-mjourdan@baylibre.com
-
Maxime Jourdan authored
We want the video decoder clocks to always round to closest. While the muxes are already using CLK_MUX_ROUND_CLOSEST, the corresponding CLK_DIVIDER_ROUND_CLOSEST was forgotten for the dividers. Fix this by adding the flag to the two vdec dividers. Fixes: a565242e ("clk: meson: gxbb: add the video decoder clocks") Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319102537.2043-1-mjourdan@baylibre.com
-
- 18 Mar, 2019 1 commit
-
-
Matthias Wieloch authored
The prescaler formula of the programmable clock has changed for sama5d2. Update the driver accordingly. Fixes: a2038077 ("clk: at91: add sama5d2 PMC driver") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> [nicolas.ferre@microchip.com: adapt the prescaler range, fix clk_programmable_recalc_rate, split patch] Signed-off-by: Matthias Wieloch <matthias.wieloch@few-bauer.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-
- 17 Mar, 2019 14 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuildLinus Torvalds authored
Pull more Kbuild updates from Masahiro Yamada: - add more Build-Depends to Debian source package - prefix header search paths with $(srctree)/ - make modpost show verbose section mismatch warnings - avoid hard-coded CROSS_COMPILE for h8300 - fix regression for Debian make-kpkg command - add semantic patch to detect missing put_device() - fix some warnings of 'make deb-pkg' - optimize NOSTDINC_FLAGS evaluation - add warnings about redundant generic-y - clean up Makefiles and scripts * tag 'kbuild-v5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: remove stale lxdialog/.gitignore kbuild: force all architectures except um to include mandatory-y kbuild: warn redundant generic-y Revert "modsign: Abort modules_install when signing fails" kbuild: Make NOSTDINC_FLAGS a simply expanded variable kbuild: deb-pkg: avoid implicit effects coccinelle: semantic code search for missing put_device() kbuild: pkg: grep include/config/auto.conf instead of $KCONFIG_CONFIG kbuild: deb-pkg: introduce is_enabled and if_enabled_echo to builddeb kbuild: deb-pkg: add CONFIG_ prefix to kernel config options kbuild: add workaround for Debian make-kpkg kbuild: source include/config/auto.conf instead of ${KCONFIG_CONFIG} unicore32: simplify linker script generation for decompressor h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux- kbuild: move archive command to scripts/Makefile.lib modpost: always show verbose warning for section mismatch ia64: prefix header search path with $(srctree)/ libfdt: prefix header search paths with $(srctree)/ deb-pkg: generate correct build dependencies
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 asm updates from Thomas Gleixner: "Two cleanup patches removing dead conditionals and unused code" * 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/asm: Remove unused __constant_c_x_memset() macro and inlines x86/asm: Remove dead __GNUC__ conditionals
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Thomas Gleixner: "Three fixes for the fallout from the TSX errata workaround: - Prevent memory corruption caused by a unchecked out of bound array index. - Two trivial fixes to address compiler warnings" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Make dev_attr_allow_tsx_force_abort static perf/x86: Fixup typo in stub functions perf/x86/intel: Fix memory corruption
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull xen fix from Juergen Gross: "A fix for a Xen bug introduced by David's series for excluding ballooned pages in vmcores" * tag 'for-linus-5.1b-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/balloon: Fix mapping PG_offline pages to user space
-
git://github.com/martinetd/linuxLinus Torvalds authored
Pull 9p updates from Dominique Martinet: "Here is a 9p update for 5.1; there honestly hasn't been much. Two fixes (leak on invalid mount argument and possible deadlock on i_size update on 32bit smp) and a fall-through warning cleanup" * tag '9p-for-5.1' of git://github.com/martinetd/linux: 9p/net: fix memory leak in p9_client_create 9p: use inode->i_lock to protect i_size_write() under 32-bit 9p: mark expected switch fall-through
-
kbuild test robot authored
Fixes: 400816f6 ("perf/x86/intel: Implement support for TSX Force Abort") Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: kbuild-all@01.org Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190313184243.GA10820@lkp-sb-ep06
-
Masahiro Yamada authored
When this .gitignore was added, lxdialog was an independent hostprogs-y. Now that all objects in lxdialog/ are directly linked to mconf, the lxdialog is no longer generated. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes the common Kbuild.asm file. Factor out the duplicated include directives to scripts/Makefile.asm-generic so that no architecture would opt out of the mandatory-y mechanism. um is not forced to include mandatory-y since it is a very exceptional case which does not support UAPI. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The generic-y is redundant under the following condition: - arch has its own implementation - the same header is added to generated-y - the same header is added to mandatory-y If a redundant generic-y is found, the warning like follows is displayed: scripts/Makefile.asm-generic:20: redundant generic-y found in arch/arm/include/asm/Kbuild: timex.h I fixed up arch Kbuild files found by this. Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Douglas Anderson authored
This reverts commit caf6fe91. The commit was fine but is no longer needed as of commit 3a2429e1 ("kbuild: change if_changed_rule for multi-line recipe"). Let's go back to using ";" to be consistent. For some discussion, see: https://lkml.kernel.org/r/CAK7LNASde0Q9S5GKeQiWhArfER4S4wL1=R_FW8q0++_X3T5=hQ@mail.gmail.comSigned-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Douglas Anderson authored
During a simple no-op (nothing changed) build I saw 39 invocations of the C compiler with the argument "-print-file-name=include". We don't need to call the C compiler 39 times for this--one time will suffice. Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid this since there doesn't appear to be any reason it should be recursively expanded. On my build this shaved ~400 ms off my "no-op" build. Note that the recursive expansion seems to date back to the (really old) commit e8f5bdb0 ("[PATCH] Makefile include path ordering"). It's a little unclear to me if the point of that patch was to switch the variable to be recursively expanded (which it did) or to avoid directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because someone else (out of tree?) was setting it. I presume later since if the only goal was to switch to recursive expansion the patch would have just removed the ":". Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Arseny Maslennikov authored
* The man page for dpkg-source(1) notes: > -b, --build directory [format-specific-parameters] > Build a source package (--build since dpkg 1.17.14). > <...> > > dpkg-source will build the source package with the first > format found in this ordered list: the format indicated > with the --format command line option, the format > indicated in debian/source/format, “1.0”. The fallback > to “1.0” is deprecated and will be removed at some point > in the future, you should always document the desired > source format in debian/source/format. See section > SOURCE PACKAGE FORMATS for an extensive description of > the various source package formats. Thus it would be more foolproof to explicitly use 1.0 (as we always did) than to rely on dpkg-source's defaults. * In a similar vein, debian/rules is not made executable by mkdebian, and dpkg-source warns about that but still silently fixes the file. Let's be explicit once again. Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Wen Yang authored
The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. The implementation of this semantic code search is: In a function, for a local variable returned by calling of_find_device_by_node(), a, if it is released by a function such as put_device()/of_dev_put()/platform_device_put() after the last use, it is considered that there is no reference leak; b, if it is passed back to the caller via dev_get_drvdata()/platform_get_drvdata()/get_device(), etc., the reference will be released in other functions, and the current function also considers that there is no reference leak; c, for the rest of the situation, the current function should release the reference by calling put_device, this code search will report the corresponding error message. By using this semantic code search, we have found some object reference leaks, such as: commit 11907e9d ("ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe") commit a12085d1 ("mtd: rawnand: atmel: fix possible object reference leak") commit 11493f26 ("mtd: rawnand: jz4780: fix possible object reference leak") There are still dozens of reference leaks in the current kernel code. Further, for the case of b, the object returned to other functions may also have a reference leak, we will continue to develop other cocci scripts to further check the reference leak. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 16 Mar, 2019 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linuxLinus Torvalds authored
Pull pidfd system call from Christian Brauner: "This introduces the ability to use file descriptors from /proc/<pid>/ as stable handles on struct pid. Even if a pid is recycled the handle will not change. For a start these fds can be used to send signals to the processes they refer to. With the ability to use /proc/<pid> fds as stable handles on struct pid we can fix a long-standing issue where after a process has exited its pid can be reused by another process. If a caller sends a signal to a reused pid it will end up signaling the wrong process. With this patchset we enable a variety of use cases. One obvious example is that we can now safely delegate an important part of process management - sending signals - to processes other than the parent of a given process by sending file descriptors around via scm rights and not fearing that the given process will have been recycled in the meantime. It also allows for easy testing whether a given process is still alive or not by sending signal 0 to a pidfd which is quite handy. There has been some interest in this feature e.g. from systems management (systemd, glibc) and container managers. I have requested and gotten comments from glibc to make sure that this syscall is suitable for their needs as well. In the future I expect it to take on most other pid-based signal syscalls. But such features are left for the future once they are needed. This has been sitting in linux-next for quite a while and has not caused any issues. It comes with selftests which verify basic functionality and also test that a recycled pid cannot be signaled via a pidfd. Jon has written about a prior version of this patchset. It should cover the basic functionality since not a lot has changed since then: https://lwn.net/Articles/773459/ The commit message for the syscall itself is extensively documenting the syscall, including it's functionality and extensibility" * tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux: selftests: add tests for pidfd_send_signal() signal: add pidfd_send_signal() syscall
-
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimmLinus Torvalds authored
Pull device-dax updates from Dan Williams: "New device-dax infrastructure to allow persistent memory and other "reserved" / performance differentiated memories, to be assigned to the core-mm as "System RAM". Some users want to use persistent memory as additional volatile memory. They are willing to cope with potential performance differences, for example between DRAM and 3D Xpoint, and want to use typical Linux memory management apis rather than a userspace memory allocator layered over an mmap() of a dax file. The administration model is to decide how much Persistent Memory (pmem) to use as System RAM, create a device-dax-mode namespace of that size, and then assign it to the core-mm. The rationale for device-dax is that it is a generic memory-mapping driver that can be layered over any "special purpose" memory, not just pmem. On subsequent boots udev rules can be used to restore the memory assignment. One implication of using pmem as RAM is that mlock() no longer keeps data off persistent media. For this reason it is recommended to enable NVDIMM Security (previously merged for 5.0) to encrypt pmem contents at rest. We considered making this recommendation an actively enforced requirement, but in the end decided to leave it as a distribution / administrator policy to allow for emulation and test environments that lack security capable NVDIMMs. Summary: - Replace the /sys/class/dax device model with /sys/bus/dax, and include a compat driver so distributions can opt-in to the new ABI. - Allow for an alternative driver for the device-dax address-range - Introduce the 'kmem' driver to hotplug / assign a device-dax address-range to the core-mm. - Arrange for the device-dax target-node to be onlined so that the newly added memory range can be uniquely referenced by numa apis" NOTE! I'm not entirely happy with the whole "PMEM as RAM" model because we currently have special - and very annoying rules in the kernel about accessing PMEM only with the "MC safe" accessors, because machine checks inside the regular repeat string copy functions can be fatal in some (not described) circumstances. And apparently the PMEM modules can cause that a lot more than regular RAM. The argument is that this happens because PMEM doesn't necessarily get scrubbed at boot like RAM does, but that is planned to be added for the user space tooling. Quoting Dan from another email: "The exposure can be reduced in the volatile-RAM case by scanning for and clearing errors before it is onlined as RAM. The userspace tooling for that can be in place before v5.1-final. There's also runtime notifications of errors via acpi_nfit_uc_error_notify() from background scrubbers on the DIMM devices. With that mechanism the kernel could proactively clear newly discovered poison in the volatile case, but that would be additional development more suitable for v5.2. I understand the concern, and the need to highlight this issue by tapping the brakes on feature development, but I don't see PMEM as RAM making the situation worse when the exposure is also there via DAX in the PMEM case. Volatile-RAM is arguably a safer use case since it's possible to repair pages where the persistent case needs active application coordination" * tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: device-dax: "Hotplug" persistent memory for use like normal RAM mm/resource: Let walk_system_ram_range() search child resources mm/memory-hotplug: Allow memory resources to be children mm/resource: Move HMM pr_debug() deeper into resource code mm/resource: Return real error codes from walk failures device-dax: Add a 'modalias' attribute to DAX 'bus' devices device-dax: Add a 'target_node' attribute device-dax: Auto-bind device after successful new_id acpi/nfit, device-dax: Identify differentiated memory with a unique numa-node device-dax: Add /sys/class/dax backwards compatibility device-dax: Add support for a dax override driver device-dax: Move resource pinning+mapping into the common driver device-dax: Introduce bus + driver model device-dax: Start defining a dax bus model device-dax: Remove multi-resource infrastructure device-dax: Kill dax_region base device-dax: Kill dax_region ida
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull more SCSI updates from James Bottomley: "This is the final round of mostly small fixes and performance improvements to our initial submit. The main regression fix is the ia64 simscsi build failure which was missed in the serial number elimination conversion" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (24 commits) scsi: ia64: simscsi: use request tag instead of serial_number scsi: aacraid: Fix performance issue on logical drives scsi: lpfc: Fix error codes in lpfc_sli4_pci_mem_setup() scsi: libiscsi: Hold back_lock when calling iscsi_complete_task scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port scsi: hisi_sas: Set PHY linkrate when disconnected scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO scsi: hisi_sas: Change return variable type in phy_up_v3_hw() scsi: qla2xxx: check for kstrtol() failure scsi: lpfc: fix 32-bit format string warning scsi: lpfc: fix unused variable warning scsi: target: tcmu: Switch to bitmap_zalloc() scsi: libiscsi: fall back to sendmsg for slab pages scsi: qla2xxx: avoid printf format warning scsi: lpfc: resolve static checker warning in lpfc_sli4_hba_unset scsi: lpfc: Correct __lpfc_sli_issue_iocb_s4 lockdep check scsi: ufs: hisi: fix ufs_hba_variant_ops passing scsi: qla2xxx: Fix panic in qla_dfs_tgt_counters_show ...
-