* [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"
From: Bjorn Helgaas @ 2017-04-25 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421070230.16582-1-colin.king@canonical.com>
On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied with Richard's ack to pci/host-imx6 for v4.12, thanks.
FWIW, there are about 25 other occurrences of "contol" in other parts
of the tree.
> ---
> drivers/pci/dwc/pci-imx6.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index 102edcf1e261..129717ae5022 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -726,13 +726,13 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> imx6_pcie->pciephy_reset = devm_reset_control_get(dev,
> "pciephy");
> if (IS_ERR(imx6_pcie->pciephy_reset)) {
> - dev_err(dev, "Failed to get PCIEPHY reset contol\n");
> + dev_err(dev, "Failed to get PCIEPHY reset control\n");
> return PTR_ERR(imx6_pcie->pciephy_reset);
> }
>
> imx6_pcie->apps_reset = devm_reset_control_get(dev, "apps");
> if (IS_ERR(imx6_pcie->apps_reset)) {
> - dev_err(dev, "Failed to get PCIE APPS reset contol\n");
> + dev_err(dev, "Failed to get PCIE APPS reset control\n");
> return PTR_ERR(imx6_pcie->apps_reset);
> }
> break;
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll @ 2017-04-25 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda-2OQZJDQndrDg_d4iK4oecz4HNSCQPSztBFTG5Rwg8w@mail.gmail.com>
Hi Linus
On Tue, 25 Apr 2017, Linus Walleij wrote:
> On Mon, Apr 24, 2017 at 6:53 PM, Hans Ulli Kroll
> <ulli.kroll@googlemail.com> wrote:
>
> > Got NAK'ed from Rob on some ealier round due missing "device mode" on this
> > IP. I've blatantly overrided this to a host only driver.
> >
> > These are the needed changes in DT to support both modes
> > Note the -dr at the end of fotg210, to reflect this in an dual role device
>
> OK I understood the discussion such that the compatible should
> simply be ""faraday,fotg210" as that is the name of the hardware
> IP block. This is the name of the hardware name in the Faraday
> page:
> http://www.faraday-tech.com/html/Product/IPProduct/InterfaceIP/USB2_0.htm
>
> Any other string implies how it is used, so that was what I understood
> as the reason to reject it with the "-hcd" (host controller device) suffix.
>
> > +- dr_mode : indicates the working mode for "fotg210-dr" compatible
> > + controllers. Can be "host", "peripheral". Default to
> > + "host" if not defined for backward compatibility.
>
> This seems right, so it is part of the generic bindings, correct?
>
> > usb at 68000000 {
> > - compatible = "cortina,gemini-usb", "faraday,fotg210";
> > + compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
>
> But this would be wrong, because the compatible should only
> indicate what kind of hardware it is, not how it is going to be used
> (whether as host only, slave only or dual-role (OTG).
>
for compatible I think yes.
But in Rob's opinion we missed the device part of the controller.
Greetings
Hans Ulli Kroll
^ permalink raw reply
* [PATCH v3] soc: brcmstb: enable drivers for ARM64 and BMIPS
From: Florian Fainelli @ 2017-04-25 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420165548.21964-1-code@mmayer.net>
On 04/20/2017 09:55 AM, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and
> BMIPS.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Applied, thanks!
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: bcm-cygnus: Add 911360's V3D device.
From: Florian Fainelli @ 2017-04-25 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418233234.13374-1-eric@anholt.net>
On Tue, 18 Apr 2017 16:32:34 -0700, Eric Anholt <eric@anholt.net> wrote:
> This loads the VC4 driver on the 911360_entphn platform (with the
> corresponding series sent to dri-devel), which is supported by master
> of the Mesa tree.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
Applied, thanks!
--
Florian
^ permalink raw reply
* [PATCH] PCI: imx6: fix spelling mistake: "contol" -> "control"
From: Joe Perches @ 2017-04-25 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425190429.GA29024@bhelgaas-glaptop.roam.corp.google.com>
On Tue, 2017-04-25 at 14:04 -0500, Bjorn Helgaas wrote:
> On Fri, Apr 21, 2017 at 08:02:30AM +0100, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > trivial fix to spelling mistake in dev_err message
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Applied with Richard's ack to pci/host-imx6 for v4.12, thanks.
>
> FWIW, there are about 25 other occurrences of "contol" in other parts
> of the tree.
Colin seems to focus on the logging format strings and
not code comments.
Other than these 2, there are 28 other instances in -next.
All of them are not output anywhere, these are just source
code comments.
$ git grep -w -i -E "contoller|contol" | wc -l
30
^ permalink raw reply
* [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT
From: Matthias Kaehlcke @ 2017-04-25 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-5G-o_jRXdJS0u_AHpjZ1Zg7dAVvD0cXn9nyC7oD==YA@mail.gmail.com>
El Tue, Apr 25, 2017 at 07:06:30PM +0100 Ard Biesheuvel ha dit:
> On 25 April 2017 at 18:39, Matthias Kaehlcke <mka@chromium.org> wrote:
> > Hi,
> >
> > El Tue, Apr 18, 2017 at 04:35:02PM +0100 Ard Biesheuvel ha dit:
> >
> >> On 18 April 2017 at 15:47, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >> > On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
> >> >> The operand is an integer constant, make the constness explicit by
> >> >> adding the modifier. This is needed for clang to generate valid code
> >> >> and also works with gcc.
> >> >
> >> > Actually it doesn't work with all gcc. I've got an older arm64 toolchain that I
> >> > only use for syntax checking (and hence I don't care if it is the latest and
> >> > greatest) and this commit breaks it:
> >> >
> >> > arch/arm64/crypto/sha1-ce-glue.c:21:2: error: invalid 'asm': invalid
> >> > operand prefix '%c'
> >> > asm(".globl " #sym "; .set " #sym ", %c0" :: "i"(val));
> >> >
> >> > I'm currently reverting this change locally so I can continue to use the old
> >> > toolchain:
> >> >
> >> > $ aarch64-linux-gnu-gcc --version
> >> > aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro
> >> > GCC 2013.11) 4.8.3 20131202 (prerelease)
> >> > Copyright (C) 2013 Free Software Foundation, Inc.
> >> >
> >> > $ aarch64-linux-gnu-as --version
> >> > GNU assembler (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro GCC
> >> > 2013.11) 2.24.0.20131220
> >> > Copyright 2013 Free Software Foundation, Inc.
> >> >
> >> > Maybe it is finally too old and nobody cares, but I thought it worth a mention.
> >> >
> >>
> >> Thanks for the report. I think we care more about GCC 4.8 than about
> >> Clang, which argues for reverting this patch.
> >>
> >> I understand these issues must be frustrating if you are working on
> >> this stuff, but to me, it is not entirely obvious why we want to
> >> support Clang in the first place (i.e., what does it buy you if your
> >> distro/environment is not already using Clang for userland), and why
> >> the burden is on Linux to make modifications to support Clang,
> >> especially when it comes to GCC extensions such as inline assembly
> >> syntax.
> >>
> >> It is ultimately up to the maintainers to decide what to do with this
> >> patch, but my vote would be to revert it, especially given that the %c
> >> placeholder prefix is not documented anywhere, and appears to simply
> >> trigger some GCC internals that happen to do the right thing in this
> >> case.
> >>
> >> However, the I -> i change is arguably an improvement, and considering
> >> that the following
> >>
> >> asm("foo: .long %0" :: "i"(some value))
> >>
> >> doesn't compile with clang either, I suggest you (Matthias) file a bug
> >> against Clang to get this fixed, and we can propose another patch just
> >> for the I->i change.
> >
> > I consulted with folks with more expertise in this area than myself.
> > This is their analysis of the situation:
> >
> > "The ARM ARM specifies that the correct AArch64 instruction assembly
> > syntax is to have a hash sign (#) before an immediate.
> >
>
> It does not specify that at all:
>
> """
> The A64 assembly language does not require the # character to
> introduce constant immediate operands, but an assembler must allow
> immediate values introduced with or without the # character. ARM
> recommends that an A64 disassembler outputs a # before an immediate
> operand.
> """
> (ARM DDI 0487A.g page C1-121)
>
> IOW, it only /recommends/ the # sign for *dis*assemblers. Big difference.
Indeed, thanks for the clarification.
> > Therefore, every time an inline assembly constraint is used that
> > specifies to print an immediate (like 'i' or 'I'), the immediate
> > (e.g. 42) should be printed with the hash (e.g. #42).
> >
> > Therefore, if you're using an immediate constraint where the hash sign
> > must not be printed, you have to use the "c" operand modifier. The "c"
> > operand modifier apparently got introduced to gcc after the 4.8
> > release.
> >
>
> My problem with the %c modifier is that it is completely undocumented,
> and appears in an internal GCC code generation code path. IOW, the GCC
> developers could also remove it at any time (although this is highly
> unlikely, of course)
clang documents it, but for GCC it is only mentioned under "x86
Operand Modifiers".
> > The binutils assembler and the clang integrated assembler accept
> > immediates without the hash sign as a non-official extension.
>
> Nope. *That* is mandated by the ARM ARM, see above.
>
> > Some of
> > the immediate constraints on gcc seem to not print out the hash sign
> > either; which is why the variant in the linux kernel works with gcc.
> >
>
> Yes, and since it is perfectly legal for the "i" constraint not to
> have a #, I don't understand what the big deal is tbh.
>
> > In summary, it seems to me that the inline assembly with the %c0
> > operand is the correct one and gcc 4.8 is simply too old to support
> > this."
> >
>
> OK, so we're back to having to choose between GCC 4.8 and Clang.
That's not what I suggested.
> > If the above is correct it seems that the solution is not to "fix"
> > clang, but to use different instructions for gcc<=4.8 and newer
> > compilers. I am aware that this is not a popular option.
> >
> > What do you think?
> >
>
> Perhaps I should just rework the code not to rely on inline asm at all.
That sounds like a good option if it is not too much of a hassle.
> I will take a look,
Thanks!
Matthias
^ permalink raw reply
* [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-04-25 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418201702.57019-2-code@mmayer.net>
Hi Rob,
On 18 April 2017 at 13:17, Markus Mayer <code@mmayer.net> wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
Would you be able to have a look at this binding? The driver won't be
upstreamed as hwmon driver (as per Guenter's comments). I am currently
converting the driver to a "soc" driver instead, but the proposed
binding remains unchanged.
If you have comments or suggestions, I would like to incorporate them
with the new series I will be sending out.
Thanks,
-Markus
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> .../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
> new file mode 100644
> index 0000000..3519197
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
> @@ -0,0 +1,68 @@
> +DDR PHY Front End (DPFE) for Broadcom STB
> +=========================================
> +
> +DPFE and the DPFE firmware provide an interface for the host CPU to
> +communicate with the DCPU, which resides inside the DDR PHY.
> +
> +There are three memory regions for interacting with the DCPU.
> +
> +The DCPU Register Space
> +-----------------------
> +
> +Required properties:
> + - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
> + or brcm,dpfe-cpu
> + - reg: must reference the start address and length of the DCPU register
> + space
> +
> +Optional properties:
> + - cell-index: the index of the DPFE instance; will default to 0 if not set
> +
> +Example:
> + dpfe_cpu0: dpfe-cpu at f1132000 {
> + compatible = "brcm,bcm7271-dpfe-cpu",
> + "brcm,dpfe-cpu-v12.0.0.0",
> + "brcm,dpfe-cpu";
> + reg = <0xf1132000 0x180>;
> + cell-index = <0>;
> + };
> +
> +The DCPU Data Memory Space
> +--------------------------
> +
> +Required properties:
> + - compatible: must be one of brcm,bcm7271-dpfe-dmem, brcm,dpfe-dmem-v12.0.0.0
> + or brcm,dpfe-dmem
> + - reg: must reference the start address and length of the DCPU DMEM space
> +
> +Optional properties:
> + - cell-index: the index of the DPFE instance; will default to 0 if not set
> +
> +Example:
> + dpfe_dmem0: dpfe-dmem at f1134000 {
> + compatible = "brcm,bcm7271-dpfe-dmem",
> + "brcm,dpfe-dmem-v12.0.0.0",
> + "brcm,dpfe-dmem";
> + reg = <0xf1134000 0x1000>;
> + cell-index = <0>;
> + };
> +
> +The DCPU Instruction Memory Space
> +---------------------------------
> +
> +Required properties:
> + - compatible: must be one of brcm,bcm7271-dpfe-imem, brcm,dpfe-imem-v12.0.0.0
> + or brcm,dpfe-imem
> + - reg: must reference the start address and length of the DCPU IMEM space
> +
> +Optional properties:
> + - cell-index: the index of the DPFE instance; will default to 0 if not set
> +
> +Example:
> + dpfe_imem0: dpfe-imem at f1138000 {
> + compatible = "brcm,bcm7271-dpfe-imem",
> + "brcm,dpfe-imem-v12.0.0.0",
> + "brcm,dpfe-imem";
> + reg = <0xf1138000 0x4000>;
> + cell-index = <0>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] [RFC] ARM: dts: imx6sx-sdb: Drop OPP hackery
From: Marek Vasut @ 2017-04-25 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425164224.26537-1-marex@denx.de>
On 04/25/2017 06:42 PM, Marek Vasut wrote:
> The imx6sx-sdb has one power supply that drives both VDDARM_IN
> and VDDSOC_IN, which is the sw1a regulator on the PFUZE PMIC.
> Connect both inputs to the sw1a regulator on the PMIC and drop
> the OPP hackery which is no longer needed as the power framework
> will take care of the regulator configuration as needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
+CC Leonard
> ---
> Note: Fabio, if you have a chance, please give this a spin and see
> if this works.
> ---
> arch/arm/boot/dts/imx6sx-sdb.dts | 25 ++++++++-----------------
> 1 file changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
> index 5bb8fd57e7f5..c0139d7e497a 100644
> --- a/arch/arm/boot/dts/imx6sx-sdb.dts
> +++ b/arch/arm/boot/dts/imx6sx-sdb.dts
> @@ -12,23 +12,6 @@
> model = "Freescale i.MX6 SoloX SDB RevB Board";
> };
>
> -&cpu0 {
> - operating-points = <
> - /* kHz uV */
> - 996000 1250000
> - 792000 1175000
> - 396000 1175000
> - 198000 1175000
> - >;
> - fsl,soc-operating-points = <
> - /* ARM kHz SOC uV */
> - 996000 1250000
> - 792000 1175000
> - 396000 1175000
> - 198000 1175000
> - >;
> -};
> -
> &i2c1 {
> clock-frequency = <100000>;
> pinctrl-names = "default";
> @@ -145,3 +128,11 @@
> reg = <1>;
> };
> };
> +
> +®_arm {
> + vin-supply = <&sw1a_reg>;
> +};
> +
> +®_soc {
> + vin-supply = <&sw1a_reg>;
> +};
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] arm64: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()
From: Laura Abbott @ 2017-04-25 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493144543-2497-1-git-send-email-catalin.marinas@arm.com>
On 04/25/2017 11:22 AM, Catalin Marinas wrote:
> The dma_common_pages_remap() function allocates a vm_struct object and
> initialises the pages pointer to value passed as argument. However, when
> this function is called dma_common_contiguous_remap(), the pages array
> is only temporarily allocated, being freed shortly after
> dma_common_contiguous_remap() returns. Architecture code checking the
> validity of an area->pages pointer would incorrectly dereference already
> freed pointers. This has been exposed by the arm64 commit 44176bb38fa4
> ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU").
>
> Fixes: 513510ddba96 ("common: dma-mapping: introduce common remapping functions")
> Cc: Laura Abbott <labbott@redhat.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reported-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Laura Abbott <labbott@redhat.com>
> ---
>
> This is for correctness since once the arm64's mmap and get_sgtable ops
> are fixed for DMA_ATTR_FORCE_CONTIGUOUS, we would no longer see the
> issue. Anyway, it's better to get this fixed in case others trip over a
> similar issue. I added a "Fixes" tag for completeness but I'm not sure
> it's worth back-porting.
>
> drivers/base/dma-mapping.c | 29 ++++++++++++++++++++++-------
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index efd71cf4fdea..ab7071041141 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -277,8 +277,8 @@ EXPORT_SYMBOL(dma_common_mmap);
> * remaps an array of PAGE_SIZE pages into another vm_area
> * Cannot be used in non-sleeping contexts
> */
> -void *dma_common_pages_remap(struct page **pages, size_t size,
> - unsigned long vm_flags, pgprot_t prot,
> +static struct vm_struct *__dma_common_pages_remap(struct page **pages,
> + size_t size, unsigned long vm_flags, pgprot_t prot,
> const void *caller)
> {
> struct vm_struct *area;
> @@ -287,13 +287,26 @@ void *dma_common_pages_remap(struct page **pages, size_t size,
> if (!area)
> return NULL;
>
> - area->pages = pages;
> -
> if (map_vm_area(area, prot, pages)) {
> vunmap(area->addr);
> return NULL;
> }
>
> + return area;
> +}
> +
> +void *dma_common_pages_remap(struct page **pages, size_t size,
> + unsigned long vm_flags, pgprot_t prot,
> + const void *caller)
> +{
> + struct vm_struct *area;
> +
> + area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
> + if (!area)
> + return NULL;
> +
> + area->pages = pages;
> +
> return area->addr;
> }
>
> @@ -308,7 +321,7 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
> {
> int i;
> struct page **pages;
> - void *ptr;
> + struct vm_struct *area;
> unsigned long pfn;
>
> pages = kmalloc(sizeof(struct page *) << get_order(size), GFP_KERNEL);
> @@ -318,11 +331,13 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
> for (i = 0, pfn = page_to_pfn(page); i < (size >> PAGE_SHIFT); i++)
> pages[i] = pfn_to_page(pfn + i);
>
> - ptr = dma_common_pages_remap(pages, size, vm_flags, prot, caller);
> + area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
>
> kfree(pages);
>
> - return ptr;
> + if (!area)
> + return NULL;
> + return area->addr;
> }
>
> /*
>
^ permalink raw reply
* [PATCH] [RFC] ARM: dts: imx6sx-sdb: Drop OPP hackery
From: Leonard Crestez @ 2017-04-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a75000d6-aa53-92e3-c43a-58b49f18ff7e@denx.de>
On Tue, 2017-04-25 at 21:30 +0200, Marek Vasut wrote:
> On 04/25/2017 06:42 PM, Marek Vasut wrote:
> > The imx6sx-sdb has one power supply that drives both VDDARM_IN
> > and VDDSOC_IN, which is the sw1a regulator on the PFUZE PMIC.
> > Connect both inputs to the sw1a regulator on the PMIC and drop
> > the OPP hackery which is no longer needed as the power framework
> > will take care of the regulator configuration as needed.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
>
> +CC Leonard
Tested-by: Leonard Crestez <leonard.crestez@nxp.com>
The OPP hack only applies to LDO bypass mode and that is not in
upstream. When LDOs are enabled the effect is to use higher voltages
than necessary for no good reason.
Setting these higher voltages can make some boards (for example Rev B)
fail to boot with ugly semi-random crashes reminiscent of memory
corruption. These failures happen the first time the lowest idle state
is used. This patch fixes those crashes.
It's not clear exactly why the crashes happen. Perhaps waking up from
idle draws more power than is available? I don't think it matters.
I sent a very similar patch a few minutes after this one:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503241
.html
> > @@ -145,3 +128,11 @@
> > reg = <1>;
> > };
> > };
> > +
> > +®_arm {
> > + vin-supply = <&sw1a_reg>;
> > +};
> > +
> > +®_soc {
> > + vin-supply = <&sw1a_reg>;
> > +};
This is also good, it will result in lower voltages will result in
lower voltages on VDD_ARM_SOC_IN rather than a fixed 1375 mV.
--
Regards,
Leonard
^ permalink raw reply
* [v4.9-rt PATCH v2] ARM: mm: remove tasklist locking from update_sections_early()
From: Grygorii Strashko @ 2017-04-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKZR7=QmhW2uruJDxTsF_+CLd4Bp8D1NU4AvjorP8mbsg@mail.gmail.com>
On 04/21/2017 06:11 PM, Kees Cook wrote:
> On Wed, Apr 19, 2017 at 5:36 PM, Laura Abbott <labbott@redhat.com> wrote:
>> On 04/19/2017 01:10 PM, Grygorii Strashko wrote:
>>>
>>> The below backtrace can be observed on -rt kernel with CONFIG_DEBUG_RODATA
>>> option enabled:
>>>
>>> BUG: sleeping function called from invalid context at
>>> kernel/locking/rtmutex.c:993
>>> in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
>>> 1 lock held by migration/0/14:
>>> #0: (tasklist_lock){+.+...}, at: [<c01183e8>]
>>> update_sections_early+0x24/0xdc
>>> irq event stamp: 38
>>> hardirqs last enabled at (37): [<c08f6f7c>]
>>> _raw_spin_unlock_irq+0x24/0x68
>>> hardirqs last disabled at (38): [<c01fdfe8>] multi_cpu_stop+0xd8/0x138
>>> softirqs last enabled at (0): [<c01303ec>]
>>> copy_process.part.5+0x238/0x1b64
>>> softirqs last disabled at (0): [< (null)>] (null)
>>> Preemption disabled at: [<c01fe244>] cpu_stopper_thread+0x80/0x10c
>>> CPU: 0 PID: 14 Comm: migration/0 Not tainted 4.9.21-rt16-02220-g49e319c
>>> #15
>>> Hardware name: Generic DRA74X (Flattened Device Tree)
>>> [<c0112014>] (unwind_backtrace) from [<c010d370>] (show_stack+0x10/0x14)
>>> [<c010d370>] (show_stack) from [<c049beb8>] (dump_stack+0xa8/0xd4)
>>> [<c049beb8>] (dump_stack) from [<c01631a0>] (___might_sleep+0x1bc/0x2ac)
>>> [<c01631a0>] (___might_sleep) from [<c08f7244>]
>>> (__rt_spin_lock+0x1c/0x30)
>>> [<c08f7244>] (__rt_spin_lock) from [<c08f77a4>] (rt_read_lock+0x54/0x68)
>>> [<c08f77a4>] (rt_read_lock) from [<c01183e8>]
>>> (update_sections_early+0x24/0xdc)
>>> [<c01183e8>] (update_sections_early) from [<c01184b0>]
>>> (__fix_kernmem_perms+0x10/0x1c)
>>> [<c01184b0>] (__fix_kernmem_perms) from [<c01fe010>]
>>> (multi_cpu_stop+0x100/0x138)
>>> [<c01fe010>] (multi_cpu_stop) from [<c01fe24c>]
>>> (cpu_stopper_thread+0x88/0x10c)
>>> [<c01fe24c>] (cpu_stopper_thread) from [<c015edc4>]
>>> (smpboot_thread_fn+0x174/0x31c)
>>> [<c015edc4>] (smpboot_thread_fn) from [<c015a988>] (kthread+0xf0/0x108)
>>> [<c015a988>] (kthread) from [<c0108818>] (ret_from_fork+0x14/0x3c)
>>> Freeing unused kernel memory: 1024K (c0d00000 - c0e00000)
>>>
>>> The stop_machine() is called with cpus = NULL from fix_kernmem_perms() and
>>> mark_rodata_ro() which means only one CPU will execute
>>> update_sections_early() while all other CPUs will spin and wait. Hence,
>>> it's safe to remove tasklist locking from update_sections_early(). As part
>>> of this change also mark functions which are local to this module as
>>> static
>>
>> Acked-by: Laura Abbott <labbott@redhat.com>
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> Please throw this at the ARM patch tracker (with our Acks).
> http://www.arm.linux.org.uk/developer/patches/info.php
>
Done
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8672/1
--
regards,
-grygorii
^ permalink raw reply
* [PATCH 0/2] thermal: broadcom: Add NSP Thermal Support
From: Jon Mason @ 2017-04-25 20:49 UTC (permalink / raw)
To: linux-arm-kernel
This adds support for NSP to the existing Northstar thermal driver.
This code is based on patches currently in the Linux SoC Thermal git
tree. Specfically,
https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=a94cb7eeecc4104a6874339f90c5d0647359c102
Jon Mason (2):
thermal: broadcom: Allow for NSP to use ns-thermal driver
ARM: dts: NSP: Add Thermal Support
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/mach-bcm/Kconfig | 2 ++
drivers/thermal/broadcom/Kconfig | 9 +++++----
3 files changed, 33 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] thermal: broadcom: Allow for NSP to use ns-thermal driver
From: Jon Mason @ 2017-04-25 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493153351-12698-1-git-send-email-jon.mason@broadcom.com>
Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
the ns-thermal driver to be selected via menuconfig. Also, change the
ns-thermal driver to work on any iProc based SoC. Finally, tweak the
Kconfig description to mention support for NSP and make the default on
for iProc based platforms.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/mach-bcm/Kconfig | 2 ++
drivers/thermal/broadcom/Kconfig | 9 +++++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index a0e66d8..da2bfeb 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
select GPIOLIB
select ARM_AMBA
select PINCTRL
+ select THERMAL
+ select THERMAL_OF
help
This enables support for systems based on Broadcom IPROC architected SoCs.
The IPROC complex contains one or more ARM CPUs along with common
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index f0dea8a..26d706c 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -1,8 +1,9 @@
config BCM_NS_THERMAL
tristate "Northstar thermal driver"
depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
help
- Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
- BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
- with a thermal sensor that allows checking CPU temperature. This
- driver provides support for it.
+ Support for the Northstar and Northstar Plus family of SoCs (e.g.
+ BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
+ Management Unit) block with a thermal sensor that allows checking CPU
+ temperature.
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: NSP: Add Thermal Support
From: Jon Mason @ 2017-04-25 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493153351-12698-1-git-send-email-jon.mason@broadcom.com>
Add thermal support via the ns-thermal driver and create a single
thermal zone for the entire SoC.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 832795b..be6fcfb 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -383,6 +383,12 @@
<0x3f408 0x04>;
};
+ thermal: thermal at 3f2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x3f2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+ };
+
sata_phy: sata_phy at 40100 {
compatible = "brcm,iproc-nsp-sata-phy";
reg = <0x40100 0x340>;
@@ -533,4 +539,24 @@
brcm,pcie-msi-inten;
};
};
+
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ coefficients = <(-556) 418000>;
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <125000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+ };
};
--
2.7.4
^ permalink raw reply related
* [PATCH V2 0/2] correct ids for clk_testout
From: Heiko Stübner @ 2017-04-25 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
Hi Eddie,
Am Dienstag, 25. April 2017, 14:41:08 CEST schrieb Eddie Cai:
> we use clk_testout1 and clk_testout2 for camera. e.g. mipi 24M mclk. the ids
> of clk_testout1 and clk_testout2 is wrong. it's time to correct it.
Just to say, patches look good - thanks for explaining what the clocks are
going to be used for.
I'll apply them after 4.12-rc1 is released (in roughly 2.5 weeks), due to
needing a stable base for the clock-ids.
Heiko
^ permalink raw reply
* [PATCH 0/2] pinctrl: trivial: remove unneeded (void *) casts in of_match_table
From: Masahiro Yamada @ 2017-04-25 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Masahiro Yamada (2):
pinctrl: rockchip: remove unneeded (void *) casts in of_match_table
pinctrl: samsung: remove unneeded (void *) casts in of_match_table
drivers/pinctrl/pinctrl-rockchip.c | 20 ++++++++++----------
drivers/pinctrl/samsung/pinctrl-samsung.c | 20 ++++++++++----------
2 files changed, 20 insertions(+), 20 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] pinctrl: rockchip: remove unneeded (void *) casts in of_match_table
From: Masahiro Yamada @ 2017-04-25 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493156063-8446-1-git-send-email-yamada.masahiro@socionext.com>
of_device_id::data is an opaque pointer. No explicit cast is needed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/pinctrl/pinctrl-rockchip.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 7813599..da1a38f 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -2769,25 +2769,25 @@ static struct rockchip_pin_ctrl rk3399_pin_ctrl = {
static const struct of_device_id rockchip_pinctrl_dt_match[] = {
{ .compatible = "rockchip,rk1108-pinctrl",
- .data = (void *)&rk1108_pin_ctrl },
+ .data = &rk1108_pin_ctrl },
{ .compatible = "rockchip,rk2928-pinctrl",
- .data = (void *)&rk2928_pin_ctrl },
+ .data = &rk2928_pin_ctrl },
{ .compatible = "rockchip,rk3036-pinctrl",
- .data = (void *)&rk3036_pin_ctrl },
+ .data = &rk3036_pin_ctrl },
{ .compatible = "rockchip,rk3066a-pinctrl",
- .data = (void *)&rk3066a_pin_ctrl },
+ .data = &rk3066a_pin_ctrl },
{ .compatible = "rockchip,rk3066b-pinctrl",
- .data = (void *)&rk3066b_pin_ctrl },
+ .data = &rk3066b_pin_ctrl },
{ .compatible = "rockchip,rk3188-pinctrl",
- .data = (void *)&rk3188_pin_ctrl },
+ .data = &rk3188_pin_ctrl },
{ .compatible = "rockchip,rk3228-pinctrl",
- .data = (void *)&rk3228_pin_ctrl },
+ .data = &rk3228_pin_ctrl },
{ .compatible = "rockchip,rk3288-pinctrl",
- .data = (void *)&rk3288_pin_ctrl },
+ .data = &rk3288_pin_ctrl },
{ .compatible = "rockchip,rk3368-pinctrl",
- .data = (void *)&rk3368_pin_ctrl },
+ .data = &rk3368_pin_ctrl },
{ .compatible = "rockchip,rk3399-pinctrl",
- .data = (void *)&rk3399_pin_ctrl },
+ .data = &rk3399_pin_ctrl },
{},
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] pinctrl: samsung: remove unneeded (void *) casts in of_match_table
From: Masahiro Yamada @ 2017-04-25 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493156063-8446-1-git-send-email-yamada.masahiro@socionext.com>
of_device_id::data is an opaque pointer. No explicit cast is needed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index d7aa22c..3b62283 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1192,25 +1192,25 @@ static int __maybe_unused samsung_pinctrl_resume(struct device *dev)
static const struct of_device_id samsung_pinctrl_dt_match[] = {
#ifdef CONFIG_PINCTRL_EXYNOS
{ .compatible = "samsung,exynos3250-pinctrl",
- .data = (void *)exynos3250_pin_ctrl },
+ .data = exynos3250_pin_ctrl },
{ .compatible = "samsung,exynos4210-pinctrl",
- .data = (void *)exynos4210_pin_ctrl },
+ .data = exynos4210_pin_ctrl },
{ .compatible = "samsung,exynos4x12-pinctrl",
- .data = (void *)exynos4x12_pin_ctrl },
+ .data = exynos4x12_pin_ctrl },
{ .compatible = "samsung,exynos5250-pinctrl",
- .data = (void *)exynos5250_pin_ctrl },
+ .data = exynos5250_pin_ctrl },
{ .compatible = "samsung,exynos5260-pinctrl",
- .data = (void *)exynos5260_pin_ctrl },
+ .data = exynos5260_pin_ctrl },
{ .compatible = "samsung,exynos5410-pinctrl",
- .data = (void *)exynos5410_pin_ctrl },
+ .data = exynos5410_pin_ctrl },
{ .compatible = "samsung,exynos5420-pinctrl",
- .data = (void *)exynos5420_pin_ctrl },
+ .data = exynos5420_pin_ctrl },
{ .compatible = "samsung,exynos5433-pinctrl",
- .data = (void *)exynos5433_pin_ctrl },
+ .data = exynos5433_pin_ctrl },
{ .compatible = "samsung,s5pv210-pinctrl",
- .data = (void *)s5pv210_pin_ctrl },
+ .data = s5pv210_pin_ctrl },
{ .compatible = "samsung,exynos7-pinctrl",
- .data = (void *)exynos7_pin_ctrl },
+ .data = exynos7_pin_ctrl },
#endif
#ifdef CONFIG_PINCTRL_S3C64XX
{ .compatible = "samsung,s3c64xx-pinctrl",
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] pinctrl: rockchip: remove unneeded (void *) casts in of_match_table
From: Heiko Stübner @ 2017-04-25 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493156063-8446-2-git-send-email-yamada.masahiro@socionext.com>
Hi,
Am Mittwoch, 26. April 2017, 06:34:22 CEST schrieb Masahiro Yamada:
> of_device_id::data is an opaque pointer. No explicit cast is needed.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/pinctrl/pinctrl-rockchip.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index 7813599..da1a38f 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -2769,25 +2769,25 @@ static struct rockchip_pin_ctrl rk3399_pin_ctrl = {
>
> static const struct of_device_id rockchip_pinctrl_dt_match[] = {
> { .compatible = "rockchip,rk1108-pinctrl",
> - .data = (void *)&rk1108_pin_ctrl },
> + .data = &rk1108_pin_ctrl },
You should base your pinctrl-patches on top of Linus' branch, especially
as the rk1108->rv1108 is in there:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/drivers/pinctrl/pinctrl-rockchip.c?h=for-next&id=b9c6dcab265e93c47bdcd99ab7c6acda90ed669b
With the above fixed:
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Heiko
^ permalink raw reply
* [v2,1/2] ARM: module: split core and init PLT sections
From: Florian Fainelli @ 2017-04-25 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1487715177-30790-2-git-send-email-ard.biesheuvel@linaro.org>
On 02/21/2017 02:12 PM, Ard Biesheuvel wrote:
> Since commit 35fa91eed817 ("ARM: kernel: merge core and init PLTs"),
> the ARM module PLT code allocates all PLT entries in a single core
> section, since the overhead of having a separate init PLT section is
> not justified by the small number of PLT entries usually required for
> init code.
>
> However, the core and init module regions are allocated independently,
> and there is a corner case where the core region may be allocated from
> the VMALLOC region if the dedicated module region is exhausted, but the
> init region, being much smaller, can still be allocated from the module
> region. This puts the PLT entries out of reach of the relocated branch
> instructions, defeating the whole purpose of PLTs.
>
> So split the core and init PLT regions, and name the latter ".init.plt"
> so it gets allocated along with (and sufficiently close to) the .init
> sections that it serves. Also, given that init PLT entries may need to
> be emitted for branches that target the core module, modify the logic
> that disregards defined symbols to only disregard symbols that are
> defined in the same section.
>
> Fixes: 35fa91eed817 ("ARM: kernel: merge core and init PLTs")
> Reported-by: Angus Clark <angus@angusclark.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard, has this been submitted to Russell's patch tracker? If not, can you
do it?
Thanks a bunch!
--
Florian
^ permalink raw reply
* [PATCH 0/3] ARM/ARM64: silence large module first time allocation
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
done from module space will fail, produce a general OOM allocation and also a
vmap warning. The second allocation from vmalloc space may or may not be
successful, but is actually the one we are interested about in these cases.
This patch series passed __GFP_NOWARN to silence such allocations from the
ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
enabled, and also makes alloc_vmap_area() react to the caller setting
__GFP_NOWARN to silence "vmap allocation for size..." messages.
Here is an example of what we would get without these two patches, pretty
scary huh?
# insmod /mnt/nfs/huge.ko
[ 22.114143] random: nonblocking pool is initialized
[ 22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
[ 22.191873] vmalloc: allocation failure: 15729534 bytes
[ 22.197112] insmod: page allocation failure: order:0, mode:0xd0
[ 22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G O 4.1.20-1.9pre-01082-gbbbff07bc3ce #9
[ 22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
[ 22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
[ 22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
[ 22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
[ 22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
[ 22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
[ 22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
[ 22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
[ 22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
[ 22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
[ 22.292277] Mem-Info:
[ 22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
[ 22.294567] active_file:1 inactive_file:3822 isolated_file:0
[ 22.294567] unevictable:0 dirty:0 writeback:0 unstable:0
[ 22.294567] slab_reclaimable:238 slab_unreclaimable:1594
[ 22.294567] mapped:855 shmem:2950 pagetables:36 bounce:0
[ 22.294567] free:39031 free_pcp:198 free_cma:3928
[ 22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 22.371631] lowmem_reserve[]: 0 0 0 0
[ 22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 22.416249] lowmem_reserve[]: 0 0 0 0
[ 22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
[ 22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
[ 22.446130] 6789 total pagecache pages
[ 22.449889] 0 pages in swap cache
[ 22.453212] Swap cache stats: add 0, delete 0, find 0/0
[ 22.458447] Free swap = 0kB
[ 22.461334] Total swap = 0kB
[ 22.464222] 786432 pages RAM
[ 22.467110] 720896 pages HighMem/MovableOnly
[ 22.471388] 725417 pages reserved
[ 22.474711] 4096 pages cma reserved
[ 22.511310] big_init: I am a big module using 3932160 bytes of data!
Florian Fainelli (3):
mm: Silence vmap() allocation failures based on caller gfp_flags
ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
arch/arm/kernel/module.c | 11 +++++++++--
arch/arm64/kernel/module.c | 7 ++++++-
mm/vmalloc.c | 2 +-
3 files changed, 16 insertions(+), 4 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/module.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..503d1a39464a 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+#if IS_ENABLED(CONFIG_ARM_MODULE_PLTS)
+ /* Silence the initial allocation */
+ gfp_mask |= __GFP_NOWARN;
+#endif
+ p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
return p;
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: Silence non PLT allocation with CONFIG_ARM_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case, since that scares people out.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/module.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..503d1a39464a 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+#if IS_ENABLED(CONFIG_ARM_MODULE_PLTS)
+ /* Silence the initial allocation */
+ gfp_mask |= __GFP_NOWARN;
+#endif
+ p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
return p;
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
If the caller has set __GFP_NOWARN don't print the following message:
vmap allocation for size 15736832 failed: use vmalloc=<size> to increase
size.
This can happen with the ARM/Linux module loader built with
CONFIG_ARM_MODULE_PLTS=y which does a first attempt at loading a large
module from module space, then falls back to vmalloc space.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0b057628a7ba..5a788eb58741 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -521,7 +521,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
}
}
- if (printk_ratelimit())
+ if (printk_ratelimit() && !(gfp_mask & __GFP_NOWARN))
pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
size);
kfree(va);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-25 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425223332.6999-1-f.fainelli@gmail.com>
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/module.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..503d1a39464a 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+#if IS_ENABLED(CONFIG_ARM_MODULE_PLTS)
+ /* Silence the initial allocation */
+ gfp_mask |= __GFP_NOWARN;
+#endif
+ p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
return p;
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox