* [PATCH v2] MAINTAINERS: add myself as Marvell berlin SoC maintainer
From: Olof Johansson @ 2016-10-17 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929105120.374-1-jszhang@marvell.com>
On Thu, Sep 29, 2016 at 06:51:20PM +0800, Jisheng Zhang wrote:
> I would like to take maintainership for Marvell berlin SoCs.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Applied to fixes. Thanks.
-Olof
^ permalink raw reply
* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Li Yang @ 2016-10-17 21:44 UTC (permalink / raw)
To: linux-arm-kernel
Commit fefe6733e added reference to the pcie->drvdata before it is
initialized which causes a kernel panic. Fix the problem by
initializing the pcie->drvdata earlier before it is used.
Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
---
drivers/pci/host/pci-layerscape.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
index 2cb7315..958187f 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -245,6 +245,7 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
if (!pcie)
return -ENOMEM;
+ pcie->drvdata = match->data;
pp = &pcie->pp;
pp->dev = dev;
pp->ops = pcie->drvdata->ops;
@@ -256,7 +257,6 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
return PTR_ERR(pcie->pp.dbi_base);
}
- pcie->drvdata = match->data;
pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
if (!ls_pcie_is_bridge(pcie))
--
1.9.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: Update Broadcom NS2 to generic IOMMU binding
From: Ray Jui @ 2016-10-17 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2de1b15adb2f57529734a4769ef04d9cde3cc5d.1476706244.git.robin.murphy@arm.com>
Hi Robin,
On 10/17/2016 5:13 AM, Robin Murphy wrote:
> With the "mmu-masters" property now deprecated and optional, the
> generic binding offers a more efficient way to specify no masters.
>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Scott Branden <sbranden@broadcom.com>
> CC: Jon Mason <jonmason@broadcom.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> index d95dc408629a..65530e193e8a 100644
> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> @@ -248,7 +248,7 @@
> <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
> - mmu-masters;
> + #iommu-cells = <1>;
> };
>
> pinctrl: pinctrl at 6501d130 {
>
Thanks!
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Roy Zang @ 2016-10-17 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476740647-11155-1-git-send-email-leoyang.li@nxp.com>
On 10/17/2016 04:50 PM, Li Yang wrote:
> Commit fefe6733e added reference to the pcie->drvdata before it is
> initialized which causes a kernel panic. Fix the problem by
> initializing the pcie->drvdata earlier before it is used.
>
> Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
> ---
Acked-by: Roy Zang <roy.zang@nxp.com>
Roy
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option
From: Olof Johansson @ 2016-10-17 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476298306-9138-1-git-send-email-scott.branden@broadcom.com>
Hi,
On Wed, Oct 12, 2016 at 11:51 AM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Enable support for on board SPI EEPROM by turning on
> CONFIG_EEPROM_AT25. This needs to be on in order to
> boot and test the kernel with a static rootfs image
> that is not rebuilt everytime the kernel is rebuilt.
If we did this for every kernel option we'd get a huge kernel.
In general, we've said that static options for what's needed to boot
to rootfs (i.e. storage and network drivers for nfsroot) are fine to
enable statically.
I doubt you need the EEPROM driver to boot to rootfs on your system,
so please enable it as a module instead.
Look into using config fragments in case you need to modify the
options for local builds, it should be a convenient way to have a
small delta to apply to fit your internal needs, instead of completely
forking the config file.
-Olof
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Enable Intel e1000e driver
From: Olof Johansson @ 2016-10-17 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <464e62ad-476e-5a2b-cdb4-c4e7f7f34e7d@broadcom.com>
On Tue, Oct 11, 2016 at 3:38 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Arnd,
>
> On 16-10-10 12:47 AM, Arnd Bergmann wrote:
>>
>> On Saturday, October 8, 2016 1:41:04 PM CEST Scott Branden wrote:
>>>
>>> Enable support for the Intel e1000e driver
>>>
>>> Signed-off-by: Ray Jui <rjui@broadcom.com>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>
>>
>> Can we make this a loadable module and group it with the other
>> ethernet drivers?
>>
> We use a fixed rootfs image to test the kernel. For simplicity we don't
> construct a rootfs or load any modules. We just test the kernel image. So
> for us every defconfig we use needs to be set to y to use the upstreamed
> kernel.
>
> Plus, how do you NFS mount a rootfs if the ethernet driver is a loadable
> module?
Yeah, agreed that it makes sense to enable it here. Applied to fixes.
-Olof
^ permalink raw reply
* [PATCH 02/28] [v2] mtd: mtk: avoid warning in mtk_ecc_encode
From: Arnd Bergmann @ 2016-10-17 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
When building with -Wmaybe-uninitialized, gcc produces a silly false positive
warning for the mtk_ecc_encode function:
drivers/mtd/nand/mtk_ecc.c: In function 'mtk_ecc_encode':
drivers/mtd/nand/mtk_ecc.c:402:15: error: 'val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The function for some reason contains a double byte swap on big-endian
builds to get the OOB data into the correct order again, and is written
in a slightly confusing way.
Using a simple memcpy32_fromio() to read the data simplifies it a lot
so it becomes more readable and produces no warning. However, the
output might not have 32-bit alignment, so we have to use another
memcpy to avoid taking alignment faults or writing beyond the end
of the array.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: move temporary buffer into struct mtk_ecc instead of having it
on the stack, as suggested by Boris Brezillon
---
drivers/mtd/nand/mtk_ecc.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/mtk_ecc.c b/drivers/mtd/nand/mtk_ecc.c
index d54f666..dbf2562 100644
--- a/drivers/mtd/nand/mtk_ecc.c
+++ b/drivers/mtd/nand/mtk_ecc.c
@@ -86,6 +86,8 @@ struct mtk_ecc {
struct completion done;
struct mutex lock;
u32 sectors;
+
+ u8 eccdata[112];
};
static inline void mtk_ecc_wait_idle(struct mtk_ecc *ecc,
@@ -366,9 +368,8 @@ int mtk_ecc_encode(struct mtk_ecc *ecc, struct mtk_ecc_config *config,
u8 *data, u32 bytes)
{
dma_addr_t addr;
- u8 *p;
- u32 len, i, val;
- int ret = 0;
+ u32 len;
+ int ret;
addr = dma_map_single(ecc->dev, data, bytes, DMA_TO_DEVICE);
ret = dma_mapping_error(ecc->dev, addr);
@@ -393,14 +394,12 @@ int mtk_ecc_encode(struct mtk_ecc *ecc, struct mtk_ecc_config *config,
/* Program ECC bytes to OOB: per sector oob = FDM + ECC + SPARE */
len = (config->strength * ECC_PARITY_BITS + 7) >> 3;
- p = data + bytes;
- /* write the parity bytes generated by the ECC back to the OOB region */
- for (i = 0; i < len; i++) {
- if ((i % 4) == 0)
- val = readl(ecc->regs + ECC_ENCPAR(i / 4));
- p[i] = (val >> ((i % 4) * 8)) & 0xff;
- }
+ /* write the parity bytes generated by the ECC back to temp buffer */
+ __ioread32_copy(ecc->eccdata, ecc->regs + ECC_ENCPAR(0), round_up(len, 4));
+
+ /* copy into possibly unaligned OOB region with actual length */
+ memcpy(data + bytes, ecc->eccdata, len);
timeout:
dma_unmap_single(ecc->dev, addr, bytes, DMA_TO_DEVICE);
--
2.9.0
^ permalink raw reply related
* [PATCHv2 1/4] arm64: dump: Make ptdump debugfs a separate option
From: Laura Abbott @ 2016-10-17 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017105252.GA29095@leverpostej>
On 10/17/2016 03:52 AM, Mark Rutland wrote:
> Hi Laura,
>
> In looking at this, I realised I was confused about ptdump_initialize()
> previously, and now see why we can't decouple the debugfs registration
> of the kernel page tables from the rest of the ptdump init. Sorry for
> the noise on that.
>
> Aside from one issue below, this looks good to me.
>
> On Wed, Oct 12, 2016 at 03:31:59PM -0700, Laura Abbott wrote:
>> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
>> index 07b8ed0..7c35689 100644
>> --- a/arch/arm64/include/asm/ptdump.h
>> +++ b/arch/arm64/include/asm/ptdump.h
>> @@ -16,9 +16,10 @@
>> #ifndef __ASM_PTDUMP_H
>> #define __ASM_PTDUMP_H
>>
>> -#ifdef CONFIG_ARM64_PTDUMP
>> +#ifdef CONFIG_ARM64_PTDUMP_CORE
>>
>> #include <linux/mm_types.h>
>> +#include <linux/seq_file.h>
>>
>> struct addr_marker {
>> unsigned long start_address;
>> @@ -32,13 +33,15 @@ struct ptdump_info {
>> unsigned long max_addr;
>> };
>>
>> -int ptdump_register(struct ptdump_info *info, const char *name);
>> -
>> +void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
>> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
>> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name);
>> #else
>> -static inline int ptdump_register(struct ptdump_info *info, const char *name)
>> +static inline int ptdump_debugfs_register(struct ptdump_info *info,
>> + const char *name)
>> {
>> return 0;
>> }
>> -#endif /* CONFIG_ARM64_PTDUMP */
>> +#endif
>
> I think you didn't mean to remove the existing endif here?
>
> It's still needed to guard the CONFIG_ARM64_PTDUMP_CORE case, and the
> new one is needed for the new #ifdef CONFIG_ARM64_PTDUMP_DEBUGFS.
> Without it, I get a build error with this patch atop of v4.9-rc1 with
> CONFIG_ARM64_PTDUMP_DEBUGFS selected:
>
> [mark at leverpostej:~/src/linux]% uselinaro 15.08 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j10 -s
> In file included from arch/arm64/mm/ptdump_debugfs.c:4:0:
> ./arch/arm64/include/asm/ptdump.h:16:0: error: unterminated #ifndef
> #ifndef __ASM_PTDUMP_H
> ^
> make[1]: *** [arch/arm64/mm/ptdump_debugfs.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
>
> With that #endif restored, everything works fine. So FWIW, with that:
>
Ugh rebase/refactor failure on my part.
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
>
> [...]
>
>> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
>> index 7c75a8d..33d35e8 100644
>> --- a/drivers/firmware/efi/arm-runtime.c
>> +++ b/drivers/firmware/efi/arm-runtime.c
>> @@ -39,7 +39,7 @@ static struct mm_struct efi_mm = {
>> .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
>> };
>>
>> -#ifdef CONFIG_ARM64_PTDUMP
>> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
>> #include <asm/ptdump.h>
>>
>> static struct ptdump_info efi_ptdump_info = {
>> @@ -53,10 +53,9 @@ static struct ptdump_info efi_ptdump_info = {
>>
>> static int __init ptdump_init(void)
>> {
>> - return ptdump_register(&efi_ptdump_info, "efi_page_tables");
>> + return ptdump_debugfs_register(&efi_ptdump_info, "efi_page_tables");
>> }
>> device_initcall(ptdump_init);
>> -
>> #endif
>
> For the EFI changes, we'll need an ack from Ard or Matt; this should
> probably be Cc'd to the linux-efi list for that.
Good point, I'll do that for v3.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable
From: Arnd Bergmann @ 2016-10-17 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
gcc found a reference to an uninitialized variable in the error handling
of bcm_enet_open, introduced by a recent cleanup:
drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open'
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]
This makes the use of that variable conditional, so we only reference it
here after it has been used before. Unlike my normal patches, I have not
build-tested this one, as I don't currently have mips test in my
randconfig setup.
Fixes: 625eb8667d6f ("net: ethernet: broadcom: bcm63xx: use phydev from struct net_device")
Cc: Philippe Reynes <tremyfr@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index ae364c7..5370909 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1126,7 +1126,8 @@ static int bcm_enet_open(struct net_device *dev)
free_irq(dev->irq, dev);
out_phy_disconnect:
- phy_disconnect(phydev);
+ if (priv->has_phy)
+ phy_disconnect(phydev);
return ret;
}
--
2.9.0
^ permalink raw reply related
* [PATCH] clk: uniphier: add system clock support for sLD3 SoC
From: Stephen Boyd @ 2016-10-17 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476630674-29402-1-git-send-email-yamada.masahiro@socionext.com>
On 10/17, Masahiro Yamada wrote:
> I do not know why, but I missed to add this compatible string in
> the initial commit of this driver.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: uniphier: fix type of variable passed to regmap_read()
From: Stephen Boyd @ 2016-10-17 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476631555-2059-1-git-send-email-yamada.masahiro@socionext.com>
On 10/17, Masahiro Yamada wrote:
> The 3rd argument of regmap_read() takes a pointer to unsigned int.
> This driver is saved just because u32 happens to be typedef'ed as
> unsigned int, but we should not rely on that fact. Change the
> variable type just in case.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] clk: samsung: clk-exynos-audss: Fix module autoload
From: Stephen Boyd @ 2016-10-17 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476625507-21377-1-git-send-email-javier@osg.samsung.com>
On 10/16, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
> alias: platform:exynos-audss-clk
>
> After this patch:
>
> $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
> alias: platform:exynos-audss-clk
> alias: of:N*T*Csamsung,exynos5420-audss-clockC*
> alias: of:N*T*Csamsung,exynos5420-audss-clock
> alias: of:N*T*Csamsung,exynos5410-audss-clockC*
> alias: of:N*T*Csamsung,exynos5410-audss-clock
> alias: of:N*T*Csamsung,exynos5250-audss-clockC*
> alias: of:N*T*Csamsung,exynos5250-audss-clock
> alias: of:N*T*Csamsung,exynos4210-audss-clockC*
> alias: of:N*T*Csamsung,exynos4210-audss-clock
>
> Fixes: 4d252fd5719b ("clk: samsung: Allow modular build of the Audio Subsystem CLKCON driver")
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: core: add __init decoration for CLK_OF_DECLARE_DRIVER function
From: Stephen Boyd @ 2016-10-17 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475917178-15488-1-git-send-email-shawn.guo@linaro.org>
On 10/08, Shawn Guo wrote:
> The new introduced macro CLK_OF_DECLARE_DRIVER is usually used to
> declare clock driver init functions, which are mostly decorated with
> __init. Add __init decoration for CLK_OF_DECLARE_DRIVER function to
> avoid causing section mismatch warnings on client clock drivers.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: mvebu: armada-37xx-periph: Fix the clock provider registration
From: Stephen Boyd @ 2016-10-17 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87h98ovb4i.fsf@free-electrons.com>
On 10/07, Gregory CLEMENT wrote:
> Hi Stephen and Mike
>
> On jeu., sept. 29 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
> > While trying using a peripheral clock on a driver, I saw that the clock
> > pointer returned by the provider was NULL.
> >
> > The problem was a missing indirection. It was the pointer stored in the
> > hws array which needed to be updated not the value it contains.
> >
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> I saw that you already did the pull request for the clk subsystem.
>
> Do you consider to do a another pull request for the fixes?
>
> It would be nice to have this driver working since the rc1 :)
>
> For this driver an other fix is needed:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/459640.html
>
Yep I was on vacation/conferencing during the merge window. I'll
be sending off a set of fixes in a couple days.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: mvebu: armada-37xx-periph: Fix the clock provider registration
From: Stephen Boyd @ 2016-10-17 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929142855.30408-1-gregory.clement@free-electrons.com>
On 09/29, Gregory CLEMENT wrote:
> While trying using a peripheral clock on a driver, I saw that the clock
> pointer returned by the provider was NULL.
>
> The problem was a missing indirection. It was the pointer stored in the
> hws array which needed to be updated not the value it contains.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] clk: bcm2835: Clamp the PLL's requested rate to the hardware limits.
From: Stephen Boyd @ 2016-10-17 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930170727.32544-1-eric@anholt.net>
On 09/30, Eric Anholt wrote:
> Fixes setting low-resolution video modes on HDMI. Now the PLLH_PIX
> divider adjusts itself until the PLLH is within bounds.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: mvebu: armada-37xx-periph: Fix the clock gate flag
From: Stephen Boyd @ 2016-10-17 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160930083359.14943-1-gregory.clement@free-electrons.com>
On 09/30, Gregory CLEMENT wrote:
> For the gate part of the peripheral clock setting the bit disables the
> clock and clearing it enables the clock. This is not the default behavior
> of clk_gate component, so we need to use the CLK_GATE_SET_TO_DISABLE flag.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: hi6220: use CLK_OF_DECLARE_DRIVER for sysctrl and mediactrl clock init
From: Stephen Boyd @ 2016-10-17 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475933892-16021-1-git-send-email-shawn.guo@linaro.org>
On 10/08, Shawn Guo wrote:
> The hi6220-sysctrl and hi6220-mediactrl are not only clock provider but
> also reset controller. It worked fine that single sysctrl/mediactrl
> device node in DT can be used to initialize clock driver and populate
> platform device for reset controller. But it stops working after
> commit 989eafd0b609 ("clk: core: Avoid double initialization of clocks")
> gets merged. The commit sets flag OF_POPULATED during clock
> initialization to skip the platform device populating for the same
> device node. On hi6220, it effectively makes hi6220-sysctrl reset
> driver not probe any more.
>
> The patch changes hi6220 sysctrl and mediactrl clock init macro from
> CLK_OF_DECLARE to CLK_OF_DECLARE_DRIVER, so that the reset driver using
> the same hardware block can continue working.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] bus: qcom-ebi2: depend on ARCH_QCOM or COMPILE_TEST
From: Stephen Boyd @ 2016-10-17 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475582179-5085-1-git-send-email-linus.walleij@linaro.org>
On 10/04, Linus Walleij wrote:
> This hides the option for people who do not want their Kconfig
> vision cluttered (i.e. x86) and enables compile testing apart
> from the supported main arch.
>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option
From: Scott Branden @ 2016-10-17 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMijByw1FYt42toNF6pAEykks_agetQybhgMQj8nAc6xdg@mail.gmail.com>
Hi Olof,
On 16-10-17 02:58 PM, Olof Johansson wrote:
> Hi,
>
> On Wed, Oct 12, 2016 at 11:51 AM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Enable support for on board SPI EEPROM by turning on
>> CONFIG_EEPROM_AT25. This needs to be on in order to
>> boot and test the kernel with a static rootfs image
>> that is not rebuilt everytime the kernel is rebuilt.
>
> If we did this for every kernel option we'd get a huge kernel.
>
> In general, we've said that static options for what's needed to boot
> to rootfs (i.e. storage and network drivers for nfsroot) are fine to
> enable statically.
>
> I doubt you need the EEPROM driver to boot to rootfs on your system,
> so please enable it as a module instead.
>
> Look into using config fragments in case you need to modify the
> options for local builds, it should be a convenient way to have a
> small delta to apply to fit your internal needs, instead of completely
> forking the config file.
Do you allow such config fragments to be upstreamed or do we need to
maintain these in our tree?
>
>
> -Olof
>
Thanks,
Scott
^ permalink raw reply
* [PATCH 3/3] arm64: dts: Update Broadcom NS2 to generic IOMMU binding
From: Scott Branden @ 2016-10-17 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f96a6cc-7e12-6827-ce88-65e2accda576@broadcom.com>
Florian,
Could you add this to the queue?
On 16-10-17 02:50 PM, Ray Jui wrote:
> Hi Robin,
>
> On 10/17/2016 5:13 AM, Robin Murphy wrote:
>> With the "mmu-masters" property now deprecated and optional, the
>> generic binding offers a more efficient way to specify no masters.
>>
>> CC: Ray Jui <rjui@broadcom.com>
>> CC: Scott Branden <sbranden@broadcom.com>
>> CC: Jon Mason <jonmason@broadcom.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> index d95dc408629a..65530e193e8a 100644
>> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> @@ -248,7 +248,7 @@
>> <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>,
>> <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
>> - mmu-masters;
>> + #iommu-cells = <1>;
>> };
>>
>> pinctrl: pinctrl at 6501d130 {
>>
>
> Thanks!
>
> Acked-by: Ray Jui <ray.jui@broadcom.com>
Thanks,
Scott
^ permalink raw reply
* [PATCH 2/5] staging/vchi: Fix build warnings when formatting pointers on aarch64.
From: Eric Anholt @ 2016-10-17 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017202834.GA30101@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Mon, Oct 17, 2016 at 12:44:03PM -0700, Eric Anholt wrote:
>> The code was generally using "%x" to print and "(unsigned int)" to
>> cast the pointers, but we have %p for printing pointers in the same
>> format without any broken casts.
>
> I already did this work, it's all checked into my tree, and is in
> linux-next now. You were cc:ed on the patches as well.
I actually haven't seen any of those messages about the patches. It
looks like it's actually that notmuch is still failing to parse some
mails (they apparently disagree with postfix on how maildir files should
be formatted, so they just drop some mail on the floor).
I did check the staging-testing branch before I started, since that's
where things were last I knew, and didn't know it had moved to -next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/c79885f6/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: defconfig: enable EEPROM_AT25 config option
From: Olof Johansson @ 2016-10-18 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <207706e2-8fd4-748f-2ee7-3c372b447a7d@broadcom.com>
On Mon, Oct 17, 2016 at 4:24 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Olof,
>
> On 16-10-17 02:58 PM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Wed, Oct 12, 2016 at 11:51 AM, Scott Branden
>> <scott.branden@broadcom.com> wrote:
>>>
>>> Enable support for on board SPI EEPROM by turning on
>>> CONFIG_EEPROM_AT25. This needs to be on in order to
>>> boot and test the kernel with a static rootfs image
>>> that is not rebuilt everytime the kernel is rebuilt.
>>
>>
>> If we did this for every kernel option we'd get a huge kernel.
>>
>> In general, we've said that static options for what's needed to boot
>> to rootfs (i.e. storage and network drivers for nfsroot) are fine to
>> enable statically.
>>
>> I doubt you need the EEPROM driver to boot to rootfs on your system,
>> so please enable it as a module instead.
>>
>> Look into using config fragments in case you need to modify the
>> options for local builds, it should be a convenient way to have a
>> small delta to apply to fit your internal needs, instead of completely
>> forking the config file.
>
>
> Do you allow such config fragments to be upstreamed or do we need to
> maintain these in our tree?
There's no place for them upstream. Maintain locally or in a separate repo.
-Olof
^ permalink raw reply
* [PATCH] extcon: qcom-spmi-misc: Sync the extcon state on interrupt
From: Stephen Boyd @ 2016-10-18 0:16 UTC (permalink / raw)
To: linux-arm-kernel
The driver was changed after submission to use the new style APIs
like extcon_set_state(). Unfortunately, that only sets the state,
and doesn't notify any consumers that the cable state has
changed. Use extcon_set_state_sync() here instead so that we
notify cable consumers of the state change. This fixes USB
host-device role switching on the db8074 platform.
Fixes: 38085c987f52 ("extcon: Add support for qcom SPMI PMIC USB id detection hardware")
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
drivers/extcon/extcon-qcom-spmi-misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
index ca957a5f4291..b8cde096a808 100644
--- a/drivers/extcon/extcon-qcom-spmi-misc.c
+++ b/drivers/extcon/extcon-qcom-spmi-misc.c
@@ -51,7 +51,7 @@ static void qcom_usb_extcon_detect_cable(struct work_struct *work)
if (ret)
return;
- extcon_set_state(info->edev, EXTCON_USB_HOST, !id);
+ extcon_set_state_sync(info->edev, EXTCON_USB_HOST, !id);
}
static irqreturn_t qcom_usb_irq_handler(int irq, void *dev_id)
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH RESEND 1/3] clk: imx6: Mask mmdc_ch1 handshake for periph2_sel and mmdc_ch1_axi_podf
From: Fabio Estevam @ 2016-10-18 0:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Philipp Zabel <p.zabel@pengutronix.de>
MMDC CH1 is not used on i.MX6Q, so the handshake needed to change the
parent of periph2_sel or the divider of mmdc_ch1_axi_podf will never
succeed.
Disable the handshake mechanism to allow changing the frequency of
mmdc_ch1_axi, allowing to use it as a possible source for the LDB DI
clock.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/clk/imx/clk-imx6q.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index ce8ea10..66825a8 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -156,6 +156,19 @@ static struct clk ** const uart_clks[] __initconst = {
NULL
};
+#define CCM_CCDR 0x04
+
+#define CCDR_MMDC_CH1_MASK BIT(16)
+
+static void __init imx6q_mmdc_ch1_mask_handshake(void __iomem *ccm_base)
+{
+ unsigned int reg;
+
+ reg = readl_relaxed(ccm_base + CCM_CCDR);
+ reg |= CCDR_MMDC_CH1_MASK;
+ writel_relaxed(reg, ccm_base + CCM_CCDR);
+}
+
static void __init imx6q_clocks_init(struct device_node *ccm_node)
{
struct device_node *np;
@@ -297,6 +310,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
base = of_iomap(np, 0);
WARN_ON(!base);
+ imx6q_mmdc_ch1_mask_handshake(base);
+
/* name reg shift width parent_names num_parents */
clk[IMX6QDL_CLK_STEP] = imx_clk_mux("step", base + 0xc, 8, 1, step_sels, ARRAY_SIZE(step_sels));
clk[IMX6QDL_CLK_PLL1_SW] = imx_clk_mux("pll1_sw", base + 0xc, 2, 1, pll1_sw_sels, ARRAY_SIZE(pll1_sw_sels));
--
2.7.4
^ 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