* [PATCH 4/4] ARM: dts: bcm2837-rpi-3-b: add GPIO expander
From: Stefan Wahren @ 2018-01-02 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a29df633ee568e150c150debde66c0783a57c70a.1514898134.git.baruch@tkos.co.il>
Hi Baruch,
> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19 geschrieben:
>
>
> Add a description of the RPi3 GPIO expander that the VC4 firmware controls.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> index b44b3b5af00d..09dca48da2bd 100644
> --- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> @@ -23,6 +23,16 @@
> gpios = <&gpio 47 0>;
> };
> };
> +
> + soc {
unfortunately this is a common issue of the RPi firmware drivers. These nodes shouldn't be child of the soc, because it's only bound for memory mapped IO. So please move it to the same level as soc. Otherwise we get more warnings with W=1 and Rob Herring gets unhappy.
> + expgpio: expgpio {
> + compatible = "brcm,bcm2835-expgpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + firmware = <&firmware>;
Please add the gpio-line-names from Eric's patch [1].
Thanks
Stefan
[1] - https://patchwork.kernel.org/patch/9339857/
> + status = "okay";
> + };
> + };
> };
>
> /* uart0 communicates with the BT module */
> --
> 2.15.1
>
>
> _______________________________________________
> 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 01/33] clk_ops: change round_rate() to return unsigned long
From: Stephen Boyd @ 2018-01-02 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d83a5c3-6589-24bc-4ca5-4d1bbca47432@nexus-software.ie>
On 12/31, Bryan O'Donoghue wrote:
> On 30/12/17 16:36, Mikko Perttunen wrote:
> >FWIW, we had this problem some years ago with the Tegra CPU clock
> >- then it was determined that a simpler solution was to have the
> >determine_rate callback support unsigned long rates - so clock
> >drivers that need to return rates higher than 2^31 can instead
> >implement the determine_rate callback. That is what's currently
> >implemented.
> >
> >Mikko
>
> Granted we could work around it but, having both zero and less than
> zero indicate error means you can't support larger than LONG_MAX
> which is I think worth fixing.
>
Ok. But can you implement the determine_rate op instead of the
round_rate op for your clk? It's not a work-around, it's the
preferred solution. That would allow rates larger than 2^31 for
the clk without pushing through a change to all the drivers to
express zero as "error" and non-zero as the rounded rate.
I'm not entirely opposed to this approach, because we probably
don't care to pass the particular error value from a clk provider
to a clk consumer about what the error is. It's actually what we
proposed as the solution for clk_round_rate() to return values
larger than LONG_MAX to consumers. But doing that consumer API
change or this provider side change is going to require us to
evaluate all the consumers of these clks to make sure they don't
check for some error value that's less than zero. This series
does half the work, by changing the provider side, while ignoring
the consumer side and any potential fallout of the less than zero
to zero return value change.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/4] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
From: Stefan Wahren @ 2018-01-02 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bcac00c71b29c359b59053a30d817a8f17d6731d.1514898134.git.baruch@tkos.co.il>
Hi Baruch,
additionally the my comments on Michael's patches in March 2017, some new below.
> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19 geschrieben:
>
>
> From: Dave Stevenson <dave.stevenson@raspberrypi.org>
>
> Pi3 and Compute Module 3 have a GPIO expander that the
> VPU communicates with.
> There is a mailbox service that now allows control of this
> expander, so add a kernel driver that can make use of it.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> drivers/gpio/Kconfig | 7 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-bcm-exp.c | 254 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 262 insertions(+)
> create mode 100644 drivers/gpio/gpio-bcm-exp.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d6a8e851ad13..e2aab64ea772 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -128,6 +128,13 @@ config GPIO_AXP209
> help
> Say yes to enable GPIO support for the AXP209 PMIC
>
> +config GPIO_BCM_EXP
> + bool "Broadcom Exp GPIO"
same as in the binding, i don't think this is specific to Broadcom.
> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
This is too long. Please split up.
> + help
> + Turn on GPIO support for Broadcom chips using the firmware mailbox
> + to communicate with VideoCore on BCM283x chips.
> +
> config GPIO_BCM_KONA
> bool "Broadcom Kona GPIO"
> depends on OF_GPIO && (ARCH_BCM_MOBILE || COMPILE_TEST)
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 4bc24febb889..c5f481b1d53c 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
> obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
> obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
> obj-$(CONFIG_GPIO_AXP209) += gpio-axp209.o
> +obj-$(CONFIG_GPIO_BCM_EXP) += gpio-bcm-exp.o
> obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
> obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
> obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
> diff --git a/drivers/gpio/gpio-bcm-exp.c b/drivers/gpio/gpio-bcm-exp.c
> new file mode 100644
> index 000000000000..d68adafaee4a
> --- /dev/null
> +++ b/drivers/gpio/gpio-bcm-exp.c
> @@ -0,0 +1,254 @@
> +/*
> + * Broadcom expander GPIO driver
> + *
> + * Uses the firmware mailbox service to communicate with the
> + * GPIO expander on the VPU.
> + *
> + * Copyright (C) 2017 Raspberry Pi Trading Ltd.
> + *
> + * Author: Dave Stevenson <dave.stevenson@raspberrypi.org>
> + * Based on gpio-bcm-virt.c by Dom Cobley <popcornmix@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
SPDX identifier?
> +
> +#include <linux/err.h>
> +#include <linux/gpio.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/dma-mapping.h>
> +#include <soc/bcm2835/raspberrypi-firmware.h>
> +
> +#define MODULE_NAME "brcmexp-gpio"
> +#define NUM_GPIO 8
> +
> +struct brcmexp_gpio {
> + struct gpio_chip gc;
> + struct device *dev;
> + struct rpi_firmware *fw;
> +};
> +
> +struct gpio_set_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up, state;
> +};
> +
> +struct gpio_get_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up;
> +};
> +
> +struct gpio_get_set_state {
> + u32 gpio, state;
> +};
> +
> +static int brcmexp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
> +{
> + struct brcmexp_gpio *gpio;
> + struct gpio_get_config get;
> + int ret;
> +
> + gpio = container_of(gc, struct brcmexp_gpio, gc);
> +
> + get.gpio = off + gpio->gc.base; /* GPIO to update */
Please don't misuse the gpiochip base to communicate with the firmware. AFAIK the gc.base should be -1 (dynamic), so better use a define for the base.
> +
> + ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
> + &get, sizeof(get));
> + if (ret) {
> + dev_err(gpio->dev,
> + "Failed to get GPIO %u config (%d)\n", off, ret);
> + return ret;
> + }
Shouldn't we also check the in-bound status at get.gpio?
And in all the other gpio ops?
> ...
> +
> +static int brcmexp_gpio_probe(struct platform_device *pdev)
> +{
> + int err = 0;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *fw_node;
> + struct rpi_firmware *fw;
> + struct brcmexp_gpio *ucb;
> +
> + fw_node = of_parse_phandle(np, "firmware", 0);
> + if (!fw_node) {
> + dev_err(dev, "Missing firmware node\n");
> + return -ENOENT;
> + }
> +
> + fw = rpi_firmware_get(fw_node);
> + if (!fw)
> + return -EPROBE_DEFER;
> +
> + ucb = devm_kzalloc(dev, sizeof(*ucb), GFP_KERNEL);
> + if (!ucb)
> + return -EINVAL;
> +
> + ucb->fw = fw;
> + ucb->dev = dev;
> + ucb->gc.label = MODULE_NAME;
> + ucb->gc.owner = THIS_MODULE;
> + ucb->gc.of_node = np;
> + ucb->gc.base = 128;
As said above this should be -1
Stefan
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Cope with duplicated Stream IDs
From: Jayachandran C @ 2018-01-02 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102130036.GB6613@arm.com>
On Tue, Jan 02, 2018 at 01:00:36PM +0000, Will Deacon wrote:
> On Tue, Jan 02, 2018 at 12:33:14PM +0000, Robin Murphy wrote:
> > For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge
> > alias to DevFn 0.0 on the subordinate bus may match the original RID of
> > the device, resulting in the same SID being present in the device's
> > fwspec twice. This causes trouble later in arm_smmu_write_strtab_ent()
> > when we wind up visiting the STE a second time and find it already live.
> >
> > Avoid the issue by giving arm_smmu_install_ste_for_dev() the cleverness
> > to skip over duplicates. It seems mildly counterintuitive compared to
> > preventing the duplicates from existing in the first place, but since
> > the DT and ACPI probe paths build their fwspecs differently, this is
> > actually the cleanest and most self-contained way to deal with it.
> >
> > Fixes: 8f78515425da ("iommu/arm-smmu: Implement of_xlate() for SMMUv3")
> > Reported-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
> > Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> > Tested-by: Jayachandran C. <jnair@caviumnetworks.com>
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> > drivers/iommu/arm-smmu-v3.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Cheers, Robin. I'll pick this up and send to Alex later this week along with
> a couple of other fixes I have kicking around.
Thanks. Even though the Fixes: tag points to an older commit, we
really need the fix in 4.14 where another commit (10631d724def drm/pci:
Deprecate drm_pci_init/exit completely) exposed the issue.
It it is not already planned, can you please cc stable?
JC.
^ permalink raw reply
* [PATCH v2 02/21] nvmem: Introduce devm_nvmem_(un)register()
From: Andrey Smirnov @ 2018-01-02 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3ffb0f7-2d27-9c58-549f-dc44209f27c6@linaro.org>
On Tue, Jan 2, 2018 at 3:44 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> Thanks for the patch,
>
> On 01/01/18 23:22, Andrey Smirnov wrote:
>>
>> Introduce devm_nvmem_register()/devm_nvmem_unregister() to make
>> .remove() unnecessary in trivial drivers.
>>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Cc: Heiko Stuebner <heiko@sntech.de>
>> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Cc: Carlo Caione <carlo@caione.org>
>> Cc: Kevin Hilman <khilman@baylibre.com>
>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>> Cc: cphealy at gmail.com
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-mediatek at lists.infradead.org
>> Cc: linux-rockchip at lists.infradead.org
>> Cc: linux-amlogic at lists.infradead.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>> drivers/nvmem/core.c | 41
>> +++++++++++++++++++++++++++++++++++++++++
>> include/linux/nvmem-provider.h | 17 +++++++++++++++++
>> 2 files changed, 58 insertions(+)
>>
> Patch looks good, kernel doc for these exported symbols are missing, you
> should add them in next version!
>
Good point! Will do in v3.
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH v2 01/21] nvmem: core: Allow specifying device name verbatim
From: Andrey Smirnov @ 2018-01-02 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba0b8125-6094-d042-a391-edcc2f68a114@linaro.org>
On Tue, Jan 2, 2018 at 3:44 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> Thanks for the Patch,
>
> On 01/01/18 23:22, Andrey Smirnov wrote:
>>
>> Add code to allow avoid having nvmem core append a numeric suffix to
>> the end of the name by passing config->id of -1.
>>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Cc: Heiko Stuebner <heiko@sntech.de>
>> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Cc: Carlo Caione <carlo@caione.org>
>> Cc: Kevin Hilman <khilman@baylibre.com>
>> Cc: Matthias Brugger <matthias.bgg@gmail.com>
>> Cc: cphealy at gmail.com
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-mediatek at lists.infradead.org
>> Cc: linux-rockchip at lists.infradead.org
>> Cc: linux-amlogic at lists.infradead.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>> drivers/nvmem/core.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
> This looks fine for me, Can you also add a line in kernel doc about this
> behavior.
>
Sure, will do in v3.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v4 0/7] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-01-02 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d268b81e-2231-8224-50e8-c11b3fed97f2@lechnology.com>
On 01/02/2018 11:10 AM, David Lechner wrote:
>
> and add "earlyprintk" to the kernel command line options.
The "clk_ignore_unused" command line option could be useful as well
^ permalink raw reply
* [PATCH 2/4] dt-bindings: gpio: add raspberry pi GPIO expander binding
From: Stefan Wahren @ 2018-01-02 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ca1795c6e09eb89f481cdec55180b4f1165bbfd.1514898134.git.baruch@tkos.co.il>
Hi Baruch,
> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19 geschrieben:
>
>
> The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware over
> I2C. The firmware mailbox interface allows the ARM core to control the
> GPIO lines.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> .../bindings/gpio/brcm,bcm2835-expgpio.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/brcm,bcm2835-expgpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm2835-expgpio.txt b/Documentation/devicetree/bindings/gpio/brcm,bcm2835-expgpio.txt
> new file mode 100644
> index 000000000000..55257f31a9be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/brcm,bcm2835-expgpio.txt
> @@ -0,0 +1,24 @@
> +Raspberry Pi GPIO expander
> +
> +The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
> +firmware exposes a mailbox interface that allows the ARM core to control the
> +GPIO lines on the expander.
> +
> +Required properties:
> +
> +- compatible : Should be "brcm,bcm2835-expgpio"
from my understand this driver is specific to the Raspberry Pi and it's vendor is the Raspberry Pi Foundation. So i prefer Eric's suggestion of "raspberrypi,firmware-gpio", which also applies to the filename.
> +- gpio-controller : Marks the device node as a gpio controller
> +- #gpio-cells : Should be two. The first cell is the pin number, and
> + the second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
> +- firmware : Reference to the RPi firmware device node
> +
> +Example:
> +
> +expgpio: expgpio {
> + compatible = "brcm,bcm2835-expgpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + firmware = <&firmware>;
> +};
> --
> 2.15.1
>
>
> _______________________________________________
> 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] arm64: dirty memory check, enable soft dirty for arm64
From: Catalin Marinas @ 2018-01-02 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512029649-61312-1-git-send-email-bin.lu@arm.com>
Hi Bin,
On Thu, Nov 30, 2017 at 12:14:09AM -0800, Bin Lu wrote:
> pmd_dirty and pmd_mkclean for THP page MADV_FREE also were
> supported in this patch.
[...]
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -306,6 +306,28 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
> return __pgprot(pgprot_val(prot) & ~PTE_TABLE_BIT);
> }
>
> +#ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY
> +static inline bool pte_soft_dirty(pte_t pte)
> +{
> + return pte_sw_dirty(pte);
> +}
> +
> +static inline pte_t pte_mksoft_dirty(pte_t pte)
> +{
> + return pte_mkdirty(pte);
> +}
> +
> +static inline pte_t pte_clear_soft_dirty(pte_t pte)
> +{
> + return pte_mkclean(pte);
> +}
> +
> +#define pmd_soft_dirty(pmd) pte_soft_dirty(pmd_pte(pmd))
> +#define pmd_mksoft_dirty(pmd) pte_pmd(pte_mksoft_dirty(pmd_pte(pmd)))
> +#define pmd_clear_soft_dirty(pmd) pte_pmd(pte_clear_soft_dirty(pmd_pte(pmd)))
IIUC, a pmd_mkclean() would result in a pte_soft_dirty() == false. Is
this the expected behaviour with MADV_FREE? The x86 code sets both
_PAGE_DIRTY and _PAGE_SOFT_DIRTY in pmd_mkdirty() but only clears
_PAGE_DIRTY in pmd_mkclean().
--
Catalin
^ permalink raw reply
* [PATCH v6 4/5] clk: aspeed: Register gated clocks
From: Stephen Boyd @ 2018-01-02 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514584997.2743.107.camel@kernel.crashing.org>
On 12/30, Benjamin Herrenschmidt wrote:
> On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote:
> > > I noticed we do have a few i2c based clock drivers... how are they ever
> > > supposed to work ? i2c bus controllers are allowed to sleep and the i2c
> > > core takes mutexes...
> >
> > We have clk_prepare()/clk_unprepare() for sleeping suckage. You
> > can use that, and i2c based clk drivers do that today.
>
> "suckage" ? Hehe ... the suckage should rather be stuff that cannot
> sleep. Arbitrary latencies and jitter caused by too much code wanting
> to be "atomic" when unnecessary are a bad thing.
Heh. Of course.
>
> In the case of clocks like the aspeed where we have to wait for a
> rather long stabilization delay, way too long to legitimately do a non-
> sleepable delay with a lock held, do we need to do everything in
> prepare() then ?
>
Yes. If we have to wait a long time in the enable path it makes
sense to move it to the prepare path instead, if possible. That
way we avoid holding a spinlock for a long time.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [clk:clk-next 20/21] drivers/clk/sprd/div.c:42:9: error: too few arguments to function 'divider_recalc_rate'
From: Stephen Boyd @ 2018-01-02 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201712290803.E0awnApy%fengguang.wu@intel.com>
On 12/29, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> head: e717a189b1bc52a60f8c1177f277e4b6c2f0ae53
> commit: 4508d70e6a5e9ad186dd4110e59f33d20483eb31 [20/21] Merge branch 'clk-divider-container' into clk-next
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 4508d70e6a5e9ad186dd4110e59f33d20483eb31
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/clk/sprd/div.c: In function 'sprd_div_helper_recalc_rate':
> >> drivers/clk/sprd/div.c:42:9: error: too few arguments to function 'divider_recalc_rate'
> return divider_recalc_rate(&common->hw, parent_rate, val, NULL, 0);
> ^~~~~~~~~~~~~~~~~~~
> In file included from drivers/clk/sprd/div.c:8:0:
> include/linux/clk-provider.h:413:15: note: declared here
> unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
> ^~~~~~~~~~~~~~~~~~~
> >> drivers/clk/sprd/div.c:43:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
>
Thanks. Fixed up.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] arm64: dts: angler: add pstore-ramoops support
From: Kees Cook @ 2018-01-02 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514446709-19347-1-git-send-email-zhuoweizhang@yahoo.com>
On Wed, Dec 27, 2017 at 11:38 PM, <zhuoweizhang@yahoo.com> wrote:
> From: Zhuowei Zhang <zhuoweizhang@yahoo.com>
>
> Support pstore-ramoops for retrieving kernel oops and panics after reboot.
>
> The address and configs are taken from the downstream kernel's device tree.
>
> Signed-off-by: Zhuowei Zhang <zhuoweizhang@yahoo.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts
> index dfa08f5..9ce3a6e 100644
> --- a/arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts
> @@ -37,4 +37,19 @@
> pinctrl-1 = <&blsp1_uart2_sleep>;
> };
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ramoops at 1fe00000 {
> + compatible = "ramoops";
> + reg = <0 0x1fe00000 0 0x00200000>;
> + console-size = <0x100000>;
> + record-size = <0x10000>;
> + ftrace-size = <0x10000>;
> + pmsg-size = <0x80000>;
> + };
> + };
> };
> --
> 1.9.1
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH 0/4] gpio: driver for the RPi3 GPIO expander
From: Stefan Wahren @ 2018-01-02 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1514898134.git.baruch@tkos.co.il>
Hi Baruch,
> Baruch Siach <baruch@tkos.co.il> hat am 2. Januar 2018 um 14:19 geschrieben:
>
>
> The Raspberry Pi 3 has a GPIO expander that controls, among others, the
> activity LED, and the camera connector GPIOs. The GPIO expander on an I2C bus
> that is not directly controlled from the ARM core. The VC4 firmware controls
> the I2C bus, and allows the ARM core to set/get GPIO settings over its mailbox
> interface.
>
> This series adds support for the RPi3 expander.
>
> The driver is ported from the downstream kernel at
> https://github.com/raspberrypi/linux/, branch rpi-4.9.y.
>
thanks for trying to upstream this. There has been attemps by Eric Anholt (September 2016) and Michael Zoran (March 2017). Some problems like get_direction() has been fixed, but not all of them.
So please look at the followings links first:
https://patchwork.kernel.org/patch/9339859/
https://patchwork.kernel.org/patch/9339857/
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/005903.html
Stefan
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: Andi Kleen @ 2018-01-02 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <edd01090-755e-fd73-434b-b910272c625a@huawei.com>
> Can you describe how you autogenerate the JSONs? Do you have some internal
> proprietary HW file format describing events, with files supplied from HW
> designer, which you can just translate into a JSON? Would the files support
> deferencing events to improve scalability?
For Intel JSON is an official format, which is maintained for each CPU.
It is automatically generated from an internal database
https://download.01.org/perfmon/
I have some python scripts to convert these Intel JSONs into the perf
format (which has some additional headers, and is split into
different categories, and add metrics).
They have some Intel specifics, so may not be useful for you.
There's no support for dereference, each CPU gets its own unique file.
But you could do the a merge simply with the attached script which merges
two JSON files.
-Andi
-------------- next part --------------
#!/usr/bin/python
# merge json event files
# merge-json file1.json file2... > merged.json
import sys
import json
all = []
for fn in sys.argv[1:]:
jf = json.load(open(fn))
for n in jf:
all.append(n)
print json.dumps(all, sort_keys=True, indent=4, separators=(',', ': '))
^ permalink raw reply
* [PATCH] [v2] ARM: B15: fix unused label warnings
From: Russell King - ARM Linux @ 2018-01-02 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <608efeca-c913-5f38-565f-9f792b51fae3@gmail.com>
On Mon, Dec 18, 2017 at 05:21:24PM -0800, Florian Fainelli wrote:
> On 12/18/2017 08:52 AM, Arnd Bergmann wrote:
> > The new conditionally compiled code leaves some labels and one
> > variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
> > are disabled:
> >
> > arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
> > arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
> > out_unmap:
> > ^~~~~~~~~
> > arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
> > out_cpu_dead:
> > ^~~~~~~~~~~~
> > At top level:
> > arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
> >
> > This replaces the existing #ifdef conditionals with IS_ENABLED()
> > checks that let the compiler figure out for itself which code to
> > drop.
> >
> > Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Thanks Arnd!
> --
> Florian
Arnd, can you throw this at the patch system please?
Note that its now possible to add the "KernelVersion" tag in the email
headers as well as anywhere in the body. The difference is that git
tools can add headers via standard options.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] [v2] ARM: B15: fix unused label warnings
From: Florian Fainelli @ 2018-01-02 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <608efeca-c913-5f38-565f-9f792b51fae3@gmail.com>
On 12/18/2017 05:21 PM, Florian Fainelli wrote:
> On 12/18/2017 08:52 AM, Arnd Bergmann wrote:
>> The new conditionally compiled code leaves some labels and one
>> variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
>> are disabled:
>>
>> arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
>> arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
>> out_unmap:
>> ^~~~~~~~~
>> arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
>> out_cpu_dead:
>> ^~~~~~~~~~~~
>> At top level:
>> arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
>>
>> This replaces the existing #ifdef conditionals with IS_ENABLED()
>> checks that let the compiler figure out for itself which code to
>> drop.
>>
>> Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Thanks Arnd!
Arnd, if you have not done so already do you mind adding this to
Russell's patch tracker? Thanks!
--
Florian
^ permalink raw reply
* [PATCH] nokia N9: Add support for magnetometer and touchscreen
From: Sebastian Reichel @ 2018-01-02 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102131722.GA20706@amd>
Hi,
On Tue, Jan 02, 2018 at 02:17:22PM +0100, Pavel Machek wrote:
> This adds dts support for magnetometer and touchscreen on Nokia N9.
I think it makes sense to have this splitted.
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> index 39e35f8..57a6679 100644
> --- a/arch/arm/boot/dts/omap3-n9.dts
> +++ b/arch/arm/boot/dts/omap3-n9.dts
> @@ -36,6 +57,22 @@
> };
> };
> };
> +
> + touch at 4b {
touchscreen@
> + compatible = "atmel,maxtouch";
> + reg = <0x4b>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <29 2>; /* gpio_61, IRQF_TRIGGER_FALLING*/
reset-gpios = <&gpio3 17 GPIO_ACTIVE_SOMETHING>;
> + vdd-supply = <&vio>;
> + avdd-supply = <&vaux1>;
Those two are not mentioned in the binding and not supported by the
driver as far as I can see?
> + };
> +};
Touchscreen with the same settings is required for n950, so it
should be in the shared n950 + n9 file.
> +&i2c3 {
> + ak8975 at 0f {
> + compatible = "asahi-kasei,ak8975";
> + reg = <0x0f>;
> + };
> };
Looking at the N9 board file this is missing a rotation matrix. This
is supported by the binding:
Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
>
> &isp {
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180102/5da4ddb9/attachment.sig>
^ permalink raw reply
* misc: bh1770glc: move sysfs interace to Documentation/ABI
From: Aishwarya Pant @ 2018-01-02 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102130636.GA20209@amd>
On Tue, Jan 02, 2018 at 02:06:36PM +0100, Pavel Machek wrote:
> Hi!
>
> > In Documentation/misc-devices/bh1770glc.txt, there is a description of the sysfs
> > interface which could be moved to Documentation/ABI.
> >
> > Would such a change be useful?
>
> Not at the moment.
>
> > The ABI documentation format looks like the following:
> >
> > What: (the full sysfs path of the attribute)
> > Date: (date of creation)
> > KernelVersion: (kernel version it first showed up in)
> > Contact: (primary contact)
> > Description: (long description on usage)
> >
> > I am doing this in an exercise to move sysfs ABI interfaces (which are
> > documented) to their right place i.e. in Documentation/ABI along with the rest.
>
> The interface should probably be changed to iio one, to be consistent
> with other sensors such as Apds990x.
>
> If you have the hardware, help would be welcome.
Yes, makes sense for this driver to be with the iio light sensors. I don't have
the hardware for it. So, I won't move the sysfs interface to ABI.
Aishwarya
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: Florian Fainelli @ 2018-01-02 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKdD0HwdFVOBx-yeTCfcMF7DXxxFaUt+Zm06oxuVuty8Rg@mail.gmail.com>
On January 2, 2018 7:05:35 AM PST, Marcin Wojtas <mw@semihalf.com> wrote:
>2018-01-02 15:08 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>>> Indeed in of_mdio_bus_register_phy, there is of_irq_get. This is
>more
>>> a discussion for a MDIO bus / ACPI patchset, but we either find a
>way
>>> to use IRQs with ACPI obtained from child nodes or for this world
>the
>>> functionality will be limited (at least for the beginning).
>>
>> Hi Marcin
>>
>> What i want to avoid is adding something which partially works, and
>> then have to throw it all away and start again in order to add full
>> support.
>>
>> If ACPI really limits interrupts to devices, maybe we need a totally
>> different representation of MDIO and PHYs in ACPI to what it used in
>> device tree? The same may be true for the Ethernet ports of the
>mvpp2?
>> They might have to be represented as real devices, not children of a
>> device? Maybe trying to map DT to ACPI on a one-to-one basis is the
>> wrong approach?
>>
>
>In terms of PP2 controller, I'd prefer to keep as much as possible to
>describing how real hardware looks like, i.e. single common controller
>with multiple ports as its children. Those considerations are
>reflected in the DT description shape and how the driver enumerates,
>which was part of the design of the initial support. Bending the
>driver (huge amount of shared initialization and resources) to
>multiple instances just for the sake of possible avoidance of IRQ
>description in ACPI is IMO a huge and unnecessary overkill.
True, although keep in mind that Device Tree, as implemented in Linux allows for a lot of flexibility in how parent/child nodes are represented and backed or not by a corresponding struct device. I suspect ACPI is much less permissive than that and we might want to have a struct device for the whole mvpp2 controller as well as for the child ports within that controller (something you could today with device tree too, just it would be more overhead). This does not necessarily have to influence the representation within the description language but we should not be biased by how the current implementation using Device Tree has shaped both representation and implementation.
--
Florian
^ permalink raw reply
* Re: [PATCH v4 0/7] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-01-02 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+50anim4-F++Fd78tuPo9+OdKgvOZ-+jWc=0QFcng5CA@mail.gmail.com>
On 01/02/2018 09:10 AM, Adam Ford wrote:
> On Sun, Dec 31, 2017 at 5:39 PM, David Lechner <david@lechnology.com> wrote:
>> This series converts mach-davinci to use the common clock framework.
>>
>> Basically, this series does some cleanup and rearranging to get things
>> ready for the conversion. Then there is a patch to add new driver in
>> drivers/clk and finally a patch to make the conversion from the mach
>> clock drivers to the new drivers.
>>
>> I have tested this on LEGO MINDSTORMS EV3 (TI AM1808), so I am confident
>> that I haven't broken anything (too badly) in da850. But, I don't have
>> other hardware to test.
>
> I tested this on a DA850-EVM, but I was not able to successfully get it to boot.
>
> It hangs during boot with no errors, oops's, or panics, but the
> standard 4.15.0-rc5 from linux-stable booted just fine.
>
> Maybe one of the TI guys will have some suggestions, but as-is, it
> appears to break at least the DA850-evm.
>
Thanks for testing. Unfortunately, the only hardware I have is the LEGO
MINDSTORMS, so I will have to rely on others to help with the debugging.
If you or anyone else with one of these boards can make the time, please
compile with:
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
and add "earlyprintk" to the kernel command line options. You may need to
select a different UART for this depending on your board. I think UART1 is
the default in the kernel configuration.
On da850 devices comment out the line:
clk_set_parent(clk, pll1_sysclk2_clk);
in da850.c when doing earlyprintk, otherwise the UART1 and UART2 clock source
will change during boot and cause garbled output after a point.
>>
>> The one thing that I know I have broken is CPU frequency scaling on da850.
>> I don't think it was working with device tree anyway, so I can't really test
>> it with the hardware I have. I'm hoping that it will be OK to defer fixing
>> it and add device tree support at the same time.
>>
>
> I agree with you that it's broken in the device tree, but I don't
> think it ever worked.
>
>> Dependencies:
>> * This series applies on top of "ARM: davinici: move watchdog restart from
>> mach to drivers" [1][2]
>> * On da850, you will also need a patch to prevent problems with the USB PHY
>> clocks [3]
>> * Or get it all at once:
>> git fetch https://github.com/dlech/ev3dev-kernel.git common-clk-v4
>
> That is what I pulled to test.
>
> adam
>
^ permalink raw reply
* [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
From: Anson Huang @ 2018-01-02 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514912859-17691-1-git-send-email-Anson.Huang@nxp.com>
Add 696MHz operating point for i.MX6UL, only for those
parts with speed grading fuse set to 2b'10 supports
696MHz operating point, so, speed grading check is also
added for i.MX6UL in this patch, the clock tree for each
operating point are as below:
696MHz:
pll1 696000000
pll1_bypass 696000000
pll1_sys 696000000
pll1_sw 696000000
arm 696000000
528MHz:
pll2 528000000
pll2_bypass 528000000
pll2_bus 528000000
ca7_secondary_sel 528000000
step 528000000
pll1_sw 528000000
arm 528000000
396MHz:
pll2_pfd2_396m 396000000
ca7_secondary_sel 396000000
step 396000000
pll1_sw 396000000
arm 396000000
198MHz:
pll2_pfd2_396m 396000000
ca7_secondary_sel 396000000
step 396000000
pll1_sw 396000000
arm 198000000
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/cpufreq/imx6q-cpufreq.c | 46 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index d9b2c2d..cbda0cc 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -120,6 +120,10 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
clk_set_parent(secondary_sel_clk, pll2_pfd2_396m_clk);
clk_set_parent(step_clk, secondary_sel_clk);
clk_set_parent(pll1_sw_clk, step_clk);
+ if (freq_hz > clk_get_rate(pll2_bus_clk)) {
+ clk_set_rate(pll1_sys_clk, new_freq * 1000);
+ clk_set_parent(pll1_sw_clk, pll1_sys_clk);
+ }
} else {
clk_set_parent(step_clk, pll2_pfd2_396m_clk);
clk_set_parent(pll1_sw_clk, step_clk);
@@ -244,6 +248,43 @@ static void imx6q_opp_check_speed_grading(struct device *dev)
of_node_put(np);
}
+#define OCOTP_CFG3_6UL_SPEED_696MHZ 0x2
+
+static void imx6ul_opp_check_speed_grading(struct device *dev)
+{
+ struct device_node *np;
+ void __iomem *base;
+ u32 val;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
+ if (!np)
+ return;
+
+ base = of_iomap(np, 0);
+ if (!base) {
+ dev_err(dev, "failed to map ocotp\n");
+ goto put_node;
+ }
+
+ /*
+ * Speed GRADING[1:0] defines the max speed of ARM:
+ * 2b'00: Reserved;
+ * 2b'01: 528000000Hz;
+ * 2b'10: 696000000Hz;
+ * 2b'11: Reserved;
+ * We need to set the max speed of ARM according to fuse map.
+ */
+ val = readl_relaxed(base + OCOTP_CFG3);
+ val >>= OCOTP_CFG3_SPEED_SHIFT;
+ val &= 0x3;
+ if (val != OCOTP_CFG3_6UL_SPEED_696MHZ)
+ if (dev_pm_opp_disable(dev, 696000000))
+ dev_warn(dev, "failed to disable 696MHz OPP\n");
+ iounmap(base);
+put_node:
+ of_node_put(np);
+}
+
static int imx6q_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
@@ -311,7 +352,10 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
goto put_reg;
}
- imx6q_opp_check_speed_grading(cpu_dev);
+ if (of_machine_is_compatible("fsl,imx6ul"))
+ imx6ul_opp_check_speed_grading(cpu_dev);
+ else
+ imx6q_opp_check_speed_grading(cpu_dev);
/* Because we have added the OPPs here, we must free them */
free_opp = true;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx6ul: add 696MHz operating point
From: Anson Huang @ 2018-01-02 17:07 UTC (permalink / raw)
To: linux-arm-kernel
Add 696MHz operating point according to datasheet
(Rev. 0, 12/2015).
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index e0b4a46..86b3251 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -68,12 +68,14 @@
clock-latency = <61036>; /* two CLK32 periods */
operating-points = <
/* kHz uV */
+ 696000 1275000
528000 1175000
396000 1025000
198000 950000
>;
fsl,soc-operating-points = <
/* KHz uV */
+ 696000 1275000
528000 1175000
396000 1175000
198000 1175000
--
1.9.1
^ permalink raw reply related
* [PATCH V3 6/6] PCI: Add device wait after slot and bus reset
From: Sinan Kaya @ 2018-01-02 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514912423-13341-1-git-send-email-okaya@codeaurora.org>
Rev 3.1 Sec 2.3.1 Request Handling Rules indicates that a device can issue
CRS following secondary bus reset. Handle device presence gracefully.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index eae04aa..2c9e9a9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4161,7 +4161,7 @@ int pci_reset_bridge_secondary_bus(struct pci_dev *dev)
{
pcibios_reset_secondary_bus(dev);
- return 0;
+ return pci_dev_wait(dev, "bus reset", PCIE_RESET_READY_POLL_MS);
}
EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
--
1.9.1
^ permalink raw reply related
* [PATCH V3 5/6] PCI: Add a return type for pci_reset_bridge_secondary_bus()
From: Sinan Kaya @ 2018-01-02 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514912423-13341-1-git-send-email-okaya@codeaurora.org>
Getting ready to return an error from pci_reset_bridge_secondary_bus() when
device is unreachable.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
drivers/pci/pci.c | 4 +++-
include/linux/pci.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 09eae93..eae04aa 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4157,9 +4157,11 @@ void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
* Use the bridge control register to assert reset on the secondary bus.
* Devices on the secondary bus are left in power-on state.
*/
-void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
+int pci_reset_bridge_secondary_bus(struct pci_dev *dev)
{
pcibios_reset_secondary_bus(dev);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0c1335a..dbd2ad2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1094,7 +1094,7 @@ int pcie_get_minimum_link(struct pci_dev *dev, enum pci_bus_speed *speed,
int pci_try_reset_bus(struct pci_bus *bus);
void pci_reset_secondary_bus(struct pci_dev *dev);
void pcibios_reset_secondary_bus(struct pci_dev *dev);
-void pci_reset_bridge_secondary_bus(struct pci_dev *dev);
+int pci_reset_bridge_secondary_bus(struct pci_dev *dev);
void pci_update_resource(struct pci_dev *dev, int resno);
int __must_check pci_assign_resource(struct pci_dev *dev, int i);
int __must_check pci_reassign_resource(struct pci_dev *dev, int i, resource_size_t add_size, resource_size_t align);
--
1.9.1
^ permalink raw reply related
* [PATCH V3 4/6] PCI: Wait device ready after pci_pm_reset()
From: Sinan Kaya @ 2018-01-02 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514912423-13341-1-git-send-email-okaya@codeaurora.org>
Rev 3.1 Sec 2.3.1 Request Handling Rules says a device can issue CRS
following a D3hot->D0 transition. Add pci_dev_wait() call to see if
device is available before returning.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 736d809..09eae93 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4116,7 +4116,7 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, csr);
pci_dev_d3_sleep(dev);
- return 0;
+ return pci_dev_wait(dev, "PM D3->D0", PCIE_RESET_READY_POLL_MS);
}
void pci_reset_secondary_bus(struct pci_dev *dev)
--
1.9.1
^ 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