* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Jiancheng Xue @ 2016-11-17 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582C2785.2010804@hisilicon.com>
Hi Wei?
On 2016/11/16 17:31, Wei Xu wrote:
> Hi Pan,
>
> On 2016/11/16 8:56, wenpan wrote:
>> Hi Marty?
>> Does this confict with your patch? If not?I hope this could be merged first. Besides could you tell me the link to your related patch?
>
> This is the link: https://patchwork.kernel.org/patch/9334743/
>
Thank you for offering this.If I want to give some comments on Marty's patch,
what should I do?
For Marty's patch, I think there's no need to add specific config item ARCH_HIxxxx
for every chipset. Some existing chipsets depend on ARCH_HISI directly like Hi3519
and Hi3798CV200. If some options like ARM_GIC is removed from ARCH_HISI, this kind
of chipsets will must choose other place to select it. I suggest we should keep selecting
ARM_GIC under ARCH_HISI as Pan's patch do.
The code may be like this:
config ARCH_HISI
bool "Hisilicon SoC Support"
- depends on ARCH_MULTI_V7
+ depends on ARCH_MULTI_V5 || ARCH_MULTI_V6 || ARCH_MULTI_V7
select ARM_AMBA
- select ARM_GIC
+ select ARM_GIC if ARCH_MULTI_V7
+ select ARM_VIC if ARCH_MULTI_V5 || depends on ARCH_MULTI_V6
select ARM_TIMER_SP804
select POWER_RESET
select POWER_RESET_HISI
select POWER_SUPPLY
What's your opinion?
Best Regards,
Jiancheng
>> On 2016/10/17 21:48, Arnd Bergmann wrote:
>>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>>
>>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>>
>>>
>>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>>> patches for Hi3520, which I think is closely related to this one.
>>> Please try to work together so the patches don't conflict. It should
>>> be fairly straightforward since you are basically doing the same
>>> change here.
>>>
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: pankaj.dubey @ 2016-11-17 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114134813.GK1041@n2100.armlinux.org.uk>
Hi Russell,
On Monday 14 November 2016 07:18 PM, Russell King - ARM Linux wrote:
> This should be sent _to_ me because it's touching generic ARM code.
> Thanks.
>
Sorry for this.
I had included your email in CC for this patch, but looks like my email
client had some issue and this patch could not reach to your mailbox. I
will take care in future.
> On Mon, Nov 14, 2016 at 10:31:56AM +0530, Pankaj Dubey wrote:
>> Many platforms are duplicating code for enabling SCU, lets add
>> common code to enable SCU by parsing SCU device node so the duplication
>> in each platform can be avoided.
>>
>> CC: Krzysztof Kozlowski <krzk@kernel.org>
>> CC: Jisheng Zhang <jszhang@marvell.com>
>> CC: Russell King <linux@armlinux.org.uk>
>> CC: Dinh Nguyen <dinguyen@opensource.altera.com>
>> CC: Patrice Chotard <patrice.chotard@st.com>
>> CC: Linus Walleij <linus.walleij@linaro.org>
>> CC: Liviu Dudau <liviu.dudau@arm.com>
>> CC: Ray Jui <rjui@broadcom.com>
>> CC: Stephen Warren <swarren@wwwdotorg.org>
>> CC: Heiko Stuebner <heiko@sntech.de>
>> CC: Shawn Guo <shawnguo@kernel.org>
>> CC: Michal Simek <michal.simek@xilinx.com>
>> CC: Wei Xu <xuwei5@hisilicon.com>
>> CC: Andrew Lunn <andrew@lunn.ch>
>> CC: Jun Nie <jun.nie@linaro.org>
>> Suggested-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm/include/asm/smp_scu.h | 4 +++
>> arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
>> index bfe163c..fdeec07 100644
>> --- a/arch/arm/include/asm/smp_scu.h
>> +++ b/arch/arm/include/asm/smp_scu.h
>> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
>>
>> #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
>> void scu_enable(void __iomem *scu_base);
>> +void __iomem *of_scu_get_base(void);
>> +int of_scu_enable(void);
>> #else
>> static inline void scu_enable(void __iomem *scu_base) {}
>> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
>> +static inline int of_scu_enable(void) {return 0; }
>> #endif
>>
>> #endif
>> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
>> index 72f9241..d0ac3ed 100644
>> --- a/arch/arm/kernel/smp_scu.c
>> +++ b/arch/arm/kernel/smp_scu.c
>> @@ -10,6 +10,7 @@
>> */
>> #include <linux/init.h>
>> #include <linux/io.h>
>> +#include <linux/of_address.h>
>>
>> #include <asm/smp_plat.h>
>> #include <asm/smp_scu.h>
>> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
>> */
>> flush_cache_all();
>> }
>> +
>> +static const struct of_device_id scu_match[] = {
>> + { .compatible = "arm,cortex-a9-scu", },
>> + { .compatible = "arm,cortex-a5-scu", },
>> + { }
>> +};
>> +
>> +/*
>> + * Helper API to get SCU base address
>> + * In case platform DT do not have SCU node, or iomap fails
>> + * this call will fallback and will try to map via call to
>> + * scu_a9_get_base.
>> + * This will return ownership of scu_base to the caller
>> + */
>> +void __iomem *of_scu_get_base(void)
>> +{
>> + unsigned long base = 0;
>> + struct device_node *np;
>> + void __iomem *scu_base;
>> +
>> + np = of_find_matching_node(NULL, scu_match);
>> + scu_base = of_iomap(np, 0);
>> + of_node_put(np);
>> + if (!scu_base) {
>> + pr_err("%s failed to map scu_base via DT\n", __func__);
>> + if (scu_a9_has_base()) {
>> + base = scu_a9_get_base();
>> + scu_base = ioremap(base, SZ_4K);
>> + }
>> + if (!scu_base) {
>> + pr_err("%s failed to map scu_base\n", __func__);
>> + return IOMEM_ERR_PTR(-ENOMEM);
>
> I can't see the point of using error-pointers here - it's not like we
> really know why we're failing, so just return NULL.
>
>> + }
>> + }
>> + return scu_base;
>> +}
>> +
>> +/*
>> + * Enable SCU via mapping scu_base DT
>> + * If scu_base mapped successfully scu will be enabled and in case of
>> + * failure if will return non-zero error code
>> + */
>> +int of_scu_enable(void)
>> +{
>> + void __iomem *scu_base;
>> +
>> + scu_base = of_scu_get_base();
>> + if (!IS_ERR(scu_base)) {
>> + scu_enable(scu_base);
>> + iounmap(scu_base);
>> + return 0;
>> + }
>> + return PTR_ERR(scu_base);
>
> and just return your -ENOMEM here.
>
^ permalink raw reply
* [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eduardo Valentin @ 2016-11-17 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478081906-12009-1-git-send-email-kernel@martin.sperl.org>
Hello,
On Wed, Nov 02, 2016 at 10:18:20AM +0000, kernel at martin.sperl.org wrote:
> From: Martin Sperl <kernel@martin.sperl.org>
>
> Add a thermal driver for the TSENSE device of the bcm2835/6/7 SOC.
>
> If the firmware enables the HW, then the configuration is not touched.
> In case the firmware has not enabled the device, then we try to set
> it up correctly (which unfortunately can not get tested).
>
> It exposes temperature and a critical trip point
> (using a hardcoded default of 80C or the temperature configured
> in the control register by the firmware, which reads as
> 407C currently)
>
> The calibrations are (potentially) different for bcm2835, bcm2836
> and bcm2837 and can get selected by the compatible property
> in the device tree.
>
> The driver also exposes the registers via debugfs.
>
> Possible future enhancements:
> * the device has the ability to trigger interrupts on reaching
> the programmed critical temperature.
> I have no knowledge which interrupt could be responsible
> for this on the ARM side, so if we get to know which irq
> it is we can implement that.
> Instead the driver right now implements polling in 1 second intervals
> * the device can also reset the HW after the trip point
> has been reached (also with some delay, so that corrective
> actions can get taken) - this is currently not enabled by the
> firmware, but could.
> * we could define more trip points for THERMAL_TRIP_HOT
> * make the trip point limits modifiable (ops.set_trip_temp)
>
> Note:
> No support for 32-bit arm bcm2837, as there is no
> arch/arm/boot/dts/bcm2836.dtsi upstream as of now.
> 64-bit arm support is not tested
>
> Changelog:
> V1 -> V2: renamed dt-binding documentation file
> added specific settings depending on compatible
> added trip point based on register
> setting up ctrl-register if HW is not enabled by firmware
> as per recommendation of Eric (untested)
> check that clock frequency is in range
> (1.9 - 5MHz - as per comment in clk-bcm2835.c)
> added driver to multi_v7_defconfig
> V2 -> V3: made a module in multi_v7_defconfig
> fixed typo in dt-binding document
> V3 -> V4: moved driver back to thermal (not using bcm sub-directory)
> set polling interval to 1second (was 0ms, so interrupt driven)
> V4 -> V5: use correct compatiblity for different soc versions in dt
> support ARM64 for bcm2837 in devicetree and defconfig
> V5 -> V6: incorporated changes recommended by Stefan Wahren
> V6 -> V7: removed depends on ARCH_BCM2836 || ARCH_BCM2837 in Kconfig
> V7 -> V8: rebased
>
Despite the minor questions on patch 2, specially on the request to use
existing slope and offset properties, I am ok with the other DT changes.
^ permalink raw reply
* [PATCH 2/6] dt-bindings: clk: max8997: Add DT binding documentation
From: pankaj.dubey @ 2016-11-17 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114161546.oitvons6tvlazgsb@rob-hp-laptop>
Hi Rob,
On Monday 14 November 2016 09:45 PM, Rob Herring wrote:
> On Mon, Nov 07, 2016 at 03:39:32PM +0530, Pankaj Dubey wrote:
>> Add Device Tree binding documentation for the clocks
>> outputs in the Maxim-8997 Power Management IC.
>>
>> CC: Michael Turquette <mturquette@baylibre.com>
>> CC: Rob Herring <robh+dt@kernel.org>
>> CC: devicetree at vger.kernel.org
>> CC: linux-clk at vger.kernel.org
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> .../devicetree/bindings/clock/maxim,max8997.txt | 44 ++++++++++++++++++++++
>> .../bindings/regulator/max8997-regulator.txt | 3 ++
>> 2 files changed, 47 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/maxim,max8997.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/maxim,max8997.txt b/Documentation/devicetree/bindings/clock/maxim,max8997.txt
>> new file mode 100644
>> index 0000000..d2e2a74
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/maxim,max8997.txt
>> @@ -0,0 +1,44 @@
>> +Binding for Maxim MAX8997 32k clock generator block
>> +
>> +This is a part of device tree bindings of MAX8997 multi-function device.
>> +More information can be found in bindings/regulator/max8997-regulator.txt file.
>> +
>> +The MAX8997 contains two 32.768khz clock outputs that can be controlled
>> +(gated/ungated) over I2C.
>> +
>> +Following properties should be presend in main device node of the MFD chip.
>> +
>> +Required properties:
>> +
>> +- #clock-cells: from common clock binding; shall be set to 1.
>> +
>> +Optional properties:
>> +- clock-output-names: From common clock binding.
>> +
>> +Each clock is assigned an identifier and client nodes can use this identifier
>> +to specify the clock which they consume. Following indices are allowed:
>> + - 0: 32khz_ap clock,
>> + - 1: 32khz_cp clock,
>> +
>> +Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max8997.h
>> +header and can be used in device tree sources.
>> +
>> +Example: Node of the MFD chip
>> +
>> + max8997: max8997_pmic at 66 {
>
> pmic at 66 {
>
> With that:
>
> Acked-by: Rob Herring <robh@kernel.org>
>
>
Thanks for review and ack.
With above mentioned change I will post v2 soon.
Thanks,
Pankaj Dubey
^ permalink raw reply
* [PATCH 02/16] ARM: EXYNOS: use generic API to enable SCU
From: pankaj.dubey @ 2016-11-17 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115185939.GA14626@kozik-lap>
Hi Krzysztof,
On Wednesday 16 November 2016 12:29 AM, Krzysztof Kozlowski wrote:
> On Mon, Nov 14, 2016 at 10:31:57AM +0530, Pankaj Dubey wrote:
>> Now as we have of_scu_enable which takes care of mapping
>> scu base from DT, lets use it.
>>
>> This patch also fixes build failure in case !SMP caused
>> by commit SHA ID: 94210b1abb2 which is already merged in
>> krzk/for-next branch
>>
>> CC: Krzysztof Kozlowski <krzk@kernel.org>
>> CC: linux-samsung-soc at vger.kernel.org
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm/mach-exynos/common.h | 1 -
>> arch/arm/mach-exynos/platsmp.c | 30 ++++--------------------------
>> arch/arm/mach-exynos/pm.c | 4 ++--
>> arch/arm/mach-exynos/suspend.c | 14 ++++----------
>> 4 files changed, 10 insertions(+), 39 deletions(-)
>>
>
> Looks correct, for reference:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Thanks for review.
> However this depends on changes in my next/soc branch (and these changes
> were the trigger for this patchset). I can either provide a tag with
> Exynos commits or accept one with common SCU code.
>
I am not sure through which tree this series need to be taken. I will
leave this to you and ARM-SOC maintainers.
As there are few comments on few patches of this series, I will address
them and soon post v2. Though I don't see any changes will be in v2 for
exynos platform. So I will include your review tag.
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH 08/16] ARM: vexpress: use generic API for enabling SCU
From: pankaj.dubey @ 2016-11-17 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6cb4dbd-847e-832a-894b-bf8718248538@arm.com>
Hi Sudeep,
On Wednesday 16 November 2016 08:04 PM, Sudeep Holla wrote:
>
>
> On 14/11/16 05:02, Pankaj Dubey wrote:
>> Now as we have of_scu_enable which takes care of mapping
>> scu base from DT, lets use it.
>>
>> CC: Liviu Dudau <liviu.dudau@arm.com>
>> CC: Sudeep Holla <sudeep.holla@arm.com>
>
> I assume you will take this series through a single tree. Also I assume
> you may make changes around a9 SCU. I will try to test if I can get my
> setup back working. But if this patch is not changed, then
>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks for review and Ack.
Yes, plan is to take this series through a single tree.
As there are few comments for other platforms and common scu file, I
will address them and submit v2 of this series soon. But I can see there
won't be any changes for vexpress platform patch in v2, so I will
include your Ack.
Thanks,
Pankaj Dubey
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eduardo Valentin @ 2016-11-17 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478081906-12009-3-git-send-email-kernel@martin.sperl.org>
Hey Martin,
Very sorry for the late feedback. Not so sure if this one got queued
already or not. Anyways, just minor questions as follows:
On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel at martin.sperl.org wrote:
> From: Martin Sperl <kernel@martin.sperl.org>
>
> Add basic thermal driver for bcm2835 SOC.
>
> This driver currently relies on the firmware setting up the
> tsense HW block and does not set it up itself.
>
> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> Acked-by: Eric Anholt <eric@anholt.net>
> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>
> ChangeLog:
> V1 -> V2: added specific settings depending on compatiblity
> added trip point based on register
> setting up ctrl-register if HW is not enabled by firmware
> as per recommendation of Eric (untested)
> check that clock frequency is in range
> (1.9 - 5MHz - as per comment in clk-bcm2835.c)
> V2 -> V4: moved back to thermal (not using bcm sub-directory)
> set polling interval to 1second (was 0ms, so interrupt driven)
> V5 -> V6: added correct depends in KConfig
> removed defined default for RESET_DELAY
> removed obvious comments
> clarify HW setup comments if not set up by FW already
> move clk_prepare_enable to an earlier stage and add error handling
> clarify warning when TS-clock runs out of recommended range
> clk_disable_unprepare added in bcm2835_thermal_remove
> added comment on recommended temperature ranges for SOC
> V6 -> V7: removed depends on ARCH_BCM2836 || ARCH_BCM2837 in Kconfig
> V7 -> V8: rebased
> ---
> drivers/thermal/Kconfig | 8 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/bcm2835_thermal.c | 340 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 349 insertions(+)
> create mode 100644 drivers/thermal/bcm2835_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index a13541b..ab946ff 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -434,4 +434,12 @@ depends on (ARCH_QCOM && OF) || COMPILE_TEST
> source "drivers/thermal/qcom/Kconfig"
> endmenu
>
> +config BCM2835_THERMAL
> + tristate "Thermal sensors on bcm2835 SoC"
> + depends on ARCH_BCM2835 || COMPILE_TEST
> + depends on HAS_IOMEM
> + depends on OF
> + help
> + Support for thermal sensors on Broadcom bcm2835 SoCs.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index c92eb22..a10ebe0 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
> obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> +obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
> diff --git a/drivers/thermal/bcm2835_thermal.c b/drivers/thermal/bcm2835_thermal.c
> new file mode 100644
> index 0000000..3468c7b
> --- /dev/null
> +++ b/drivers/thermal/bcm2835_thermal.c
> @@ -0,0 +1,340 @@
> +/*
> + * Driver for Broadcom BCM2835 soc temperature sensor
> + *
> + * Copyright (C) 2016 Martin Sperl
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/debugfs.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define BCM2835_TS_TSENSCTL 0x00
> +#define BCM2835_TS_TSENSSTAT 0x04
> +
> +#define BCM2835_TS_TSENSCTL_PRWDW BIT(0)
> +#define BCM2835_TS_TSENSCTL_RSTB BIT(1)
> +#define BCM2835_TS_TSENSCTL_CTRL_BITS 3
> +#define BCM2835_TS_TSENSCTL_CTRL_SHIFT 2
> +#define BCM2835_TS_TSENSCTL_CTRL_MASK \
> + GENMASK(BCM2835_TS_TSENSCTL_CTRL_BITS + \
> + BCM2835_TS_TSENSCTL_CTRL_SHIFT - 1, \
> + BCM2835_TS_TSENSCTL_CTRL_SHIFT)
> +#define BCM2835_TS_TSENSCTL_CTRL_DEFAULT 1
> +#define BCM2835_TS_TSENSCTL_EN_INT BIT(5)
> +#define BCM2835_TS_TSENSCTL_DIRECT BIT(6)
> +#define BCM2835_TS_TSENSCTL_CLR_INT BIT(7)
> +#define BCM2835_TS_TSENSCTL_THOLD_SHIFT 8
> +#define BCM2835_TS_TSENSCTL_THOLD_BITS 10
> +#define BCM2835_TS_TSENSCTL_THOLD_MASK \
> + GENMASK(BCM2835_TS_TSENSCTL_THOLD_BITS + \
> + BCM2835_TS_TSENSCTL_THOLD_SHIFT - 1, \
> + BCM2835_TS_TSENSCTL_THOLD_SHIFT)
> +#define BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT 18
> +#define BCM2835_TS_TSENSCTL_RSTDELAY_BITS 8
> +#define BCM2835_TS_TSENSCTL_REGULEN BIT(26)
> +
> +#define BCM2835_TS_TSENSSTAT_DATA_BITS 10
> +#define BCM2835_TS_TSENSSTAT_DATA_SHIFT 0
> +#define BCM2835_TS_TSENSSTAT_DATA_MASK \
> + GENMASK(BCM2835_TS_TSENSSTAT_DATA_BITS + \
> + BCM2835_TS_TSENSSTAT_DATA_SHIFT - 1, \
> + BCM2835_TS_TSENSSTAT_DATA_SHIFT)
> +#define BCM2835_TS_TSENSSTAT_VALID BIT(10)
> +#define BCM2835_TS_TSENSSTAT_INTERRUPT BIT(11)
> +
> +struct bcm2835_thermal_info {
> + int offset;
> + int slope;
> + int trip_temp;
> +};
> +
> +struct bcm2835_thermal_data {
> + const struct bcm2835_thermal_info *info;
> + void __iomem *regs;
> + struct clk *clk;
> + struct dentry *debugfsdir;
> +};
> +
> +static int bcm2835_thermal_adc2temp(
> + const struct bcm2835_thermal_info *info, u32 adc)
> +{
> + return info->offset + (adc * info->slope);
Any specific reason we cannot use thermal_zone_params->slope and
thermal_zone_params->offset?
> +}
> +
> +static int bcm2835_thermal_temp2adc(
> + const struct bcm2835_thermal_info *info, int temp)
> +{
> + temp -= info->offset;
> + temp /= info->slope;
> +
> + if (temp < 0)
> + temp = 0;
> + if (temp >= BIT(BCM2835_TS_TSENSSTAT_DATA_BITS))
> + temp = BIT(BCM2835_TS_TSENSSTAT_DATA_BITS) - 1;
> +
> + return temp;
> +}
> +
> +static int bcm2835_thermal_get_trip_type(
> + struct thermal_zone_device *tz, int trip,
> + enum thermal_trip_type *type)
> +{
> + *type = THERMAL_TRIP_CRITICAL;
> + return 0;
> +}
> +
> +static int bcm2835_thermal_get_trip_temp(
> + struct thermal_zone_device *tz, int trip, int *temp)
> +{
> + struct bcm2835_thermal_data *data = tz->devdata;
> + u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
> +
> + /* get the THOLD bits */
> + val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
> + val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
> +
> + /* if it is zero then use the info value */
> + if (val)
Is this a read only register or is this driver supposed to program it?
In which scenario it would be 0? Can this be added as comments?
> + *temp = bcm2835_thermal_adc2temp(data->info, val);
> + else
> + *temp = data->info->trip_temp;
> +
> + return 0;
> +}
> +
> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
> + int *temp)
> +{
> + struct bcm2835_thermal_data *data = tz->devdata;
> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
> +
> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
What cases you would get the valid bit not set? Do you need to wait for
the conversion to finish?
> + return -EIO;
> +
> + val &= BCM2835_TS_TSENSSTAT_DATA_MASK;
> +
> + *temp = bcm2835_thermal_adc2temp(data->info, val);
> +
> + return 0;
> +}
> +
> +static const struct debugfs_reg32 bcm2835_thermal_regs[] = {
> + {
> + .name = "ctl",
> + .offset = 0
> + },
> + {
> + .name = "stat",
> + .offset = 4
> + }
> +};
> +
> +static void bcm2835_thermal_debugfs(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *tz = platform_get_drvdata(pdev);
> + struct bcm2835_thermal_data *data = tz->devdata;
> + struct debugfs_regset32 *regset;
> +
> + data->debugfsdir = debugfs_create_dir("bcm2835_thermal", NULL);
> + if (!data->debugfsdir)
> + return;
> +
> + regset = devm_kzalloc(&pdev->dev, sizeof(*regset), GFP_KERNEL);
> + if (!regset)
> + return;
> +
> + regset->regs = bcm2835_thermal_regs;
> + regset->nregs = ARRAY_SIZE(bcm2835_thermal_regs);
> + regset->base = data->regs;
> +
> + debugfs_create_regset32("regset", S_IRUGO,
> + data->debugfsdir, regset);
> +}
> +
> +static struct thermal_zone_device_ops bcm2835_thermal_ops = {
> + .get_temp = bcm2835_thermal_get_temp,
> + .get_trip_temp = bcm2835_thermal_get_trip_temp,
> + .get_trip_type = bcm2835_thermal_get_trip_type,
> +};
> +
> +static const struct of_device_id bcm2835_thermal_of_match_table[];
> +static int bcm2835_thermal_probe(struct platform_device *pdev)
> +{
> + const struct of_device_id *match;
> + struct thermal_zone_device *tz;
> + struct bcm2835_thermal_data *data;
> + struct resource *res;
> + int err;
> + u32 val;
> + unsigned long rate;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + match = of_match_device(bcm2835_thermal_of_match_table,
> + &pdev->dev);
> + if (!match)
> + return -EINVAL;
> + data->info = match->data;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->regs)) {
> + err = PTR_ERR(data->regs);
> + dev_err(&pdev->dev, "Could not get registers: %d\n", err);
> + return err;
> + }
> +
> + data->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(data->clk)) {
> + err = PTR_ERR(data->clk);
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Could not get clk: %d\n", err);
> + return err;
> + }
> +
> + err = clk_prepare_enable(data->clk);
> + if (err)
> + return err;
> +
> + rate = clk_get_rate(data->clk);
> + if ((rate < 1920000) || (rate > 5000000))
> + dev_warn(&pdev->dev,
> + "Clock %pCn running at %pCr Hz is outside of the recommended range: 1.92 to 5MHz\n",
> + data->clk, data->clk);
> +
> + /*
> + * right now the FW does set up the HW-block, so we are not
> + * touching the configuration registers.
> + * But if the HW is not enabled, then set it up
> + * using "sane" values used by the firmware right now.
> + */
> + val = readl(data->regs + BCM2835_TS_TSENSCTL);
> + if (!(val & BCM2835_TS_TSENSCTL_RSTB)) {
> + /* the basic required flags */
> + val = (BCM2835_TS_TSENSCTL_CTRL_DEFAULT <<
> + BCM2835_TS_TSENSCTL_CTRL_SHIFT) |
> + BCM2835_TS_TSENSCTL_REGULEN;
> +
> + /*
> + * reset delay using the current firmware value of 14
> + * - units of time are unknown.
> + */
> + val |= (14 << BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT);
> +
> + /* trip_adc value from info */
> + val |= bcm2835_thermal_temp2adc(data->info,
> + data->info->trip_temp) <<
> + BCM2835_TS_TSENSCTL_THOLD_SHIFT;
> +
> + /* write the value back to the register as 2 steps */
> + writel(val, data->regs + BCM2835_TS_TSENSCTL);
> + val |= BCM2835_TS_TSENSCTL_RSTB;
> + writel(val, data->regs + BCM2835_TS_TSENSCTL);
> + }
> +
> + /* register thermal zone with 1 trip point an 1s polling */
> + tz = thermal_zone_device_register("bcm2835_thermal",
> + 1, 0, data,
> + &bcm2835_thermal_ops,
> + NULL,
> + 0, 1000);
> + if (IS_ERR(tz)) {
> + clk_disable_unprepare(data->clk);
> + err = PTR_ERR(tz);
> + dev_err(&pdev->dev,
> + "Failed to register the thermal device: %d\n",
> + err);
> + return err;
> + }
> +
> + platform_set_drvdata(pdev, tz);
> +
> + bcm2835_thermal_debugfs(pdev);
> +
> + return 0;
> +}
> +
> +static int bcm2835_thermal_remove(struct platform_device *pdev)
> +{
> + struct thermal_zone_device *tz = platform_get_drvdata(pdev);
> + struct bcm2835_thermal_data *data = tz->devdata;
> +
> + debugfs_remove_recursive(data->debugfsdir);
> + thermal_zone_device_unregister(tz);
> + clk_disable_unprepare(data->clk);
> +
> + return 0;
> +}
> +
> +/*
> + * Note: as per Raspberry Foundation FAQ
> + * (https://www.raspberrypi.org/help/faqs/#performanceOperatingTemperature)
> + * the recommended temperature range for the SOC -40C to +85C
> + * so the trip limit is set to 80C.
> + * this applies to all the BCM283X SOC
> + */
> +
> +static const struct of_device_id bcm2835_thermal_of_match_table[] = {
> + {
> + .compatible = "brcm,bcm2835-thermal",
> + .data = &(struct bcm2835_thermal_info) {
> + .offset = 407000,
> + .slope = -538,
> + .trip_temp = 80000
> + }
> + },
> + {
> + .compatible = "brcm,bcm2836-thermal",
> + .data = &(struct bcm2835_thermal_info) {
> + .offset = 407000,
> + .slope = -538,
> + .trip_temp = 80000
> + }
> + },
> + {
> + .compatible = "brcm,bcm2837-thermal",
> + .data = &(struct bcm2835_thermal_info) {
> + /* the bcm2837 needs adjustment of +5C */
> + .offset = 407000 + 5000,
> + .slope = -538,
> + .trip_temp = 80000
> + }
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_thermal_of_match_table);
> +
> +static struct platform_driver bcm2835_thermal_driver = {
> + .probe = bcm2835_thermal_probe,
> + .remove = bcm2835_thermal_remove,
> + .driver = {
> + .name = "bcm2835_thermal",
> + .of_match_table = bcm2835_thermal_of_match_table,
> + },
> +};
> +module_platform_driver(bcm2835_thermal_driver);
> +
> +MODULE_AUTHOR("Martin Sperl");
> +MODULE_DESCRIPTION("Thermal driver for bcm2835 chip");
> +MODULE_LICENSE("GPL");
> --
> 2.1.4
^ permalink raw reply
* [PATCH] ARM: dts: lpc435x: remove address and size cells from gpio-keys-polled nodes
From: Vladimir Zapolskiy @ 2016-11-17 2:06 UTC (permalink / raw)
To: linux-arm-kernel
The change removes redundant #address-cells and #size-cells properties from
gpio-keys-polled compatible device nodes found in lpc4357-ea4357-devkit and
lpc4350-hitex-eval board DTS files.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 2 --
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 874c75d..7649285 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -40,8 +40,6 @@
pca_buttons {
compatible = "gpio-keys-polled";
- #address-cells = <1>;
- #size-cells = <0>;
poll-interval = <100>;
autorepeat;
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 9b5fad6..50ee2d5 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -57,8 +57,6 @@
compatible = "gpio-keys-polled";
pinctrl-names = "default";
pinctrl-0 = <&gpio_joystick_pins>;
- #address-cells = <1>;
- #size-cells = <0>;
poll-interval = <100>;
autorepeat;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Shawn Lin @ 2016-11-17 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5037506.GEHFh4fruS@phil>
Hi Heiko,
? 2016/11/16 17:58, Heiko Stuebner ??:
> Hi Shawn,
>
> Am Mittwoch, 16. November 2016, 17:33:21 CET schrieb Shawn Lin:
>> ? 2016/11/16 6:38, Heiko Stuebner ??:
>>> The General Register Files are an area of registers containing a lot
>>> of single-bit settings for numerous components as well full components
>>> like usbphy control. Therefore all used components are accessed
>>> via the syscon provided by the grf nodes or from the sub-devices
>>> created through the simple-mfd created from the grf node.
>>>
----8<----------------
[...]
>>> + for (i = 0; i < grf_info->num_values; i++) {
>>> + const struct rockchip_grf_value *val = &grf_info->values[i];
>>> +
>>> + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
>>> + val->desc, val->reg, val->val);
>>> + ret = regmap_write(grf, val->reg, val->val);
>>> + if (ret < 0)
>>> + pr_err("%s: write to %#6x failed with %d\n",
>>> + __func__, val->reg, ret);
>>
>> So, when failing to do one of the settings, should we still let it goes?
>> Sometimes the log of postcore_initcall is easy to be neglected when
>> people finally find problems later but the very earlier log was missing
>> due to whatever reason like buffer limitation, etc.
>
> I expect errors here to be very rare. I.e. Doug thought that regmap might
> return errors if we write outside the mapped region, which would mean someone
> really messed up in this core component or a core-element of the dts.
> But in general the GRF is always a mmio-regmap, so there won't be any i2c/spi/
> whatever errors possible.
I was just thinking about the scalability that in the future some of the
GRF settings may depend on genpd or clock even if they are only a
mmio-regmap but they don't belong to the general pd/clock for GRF, for
instance, some of the PHYs' or controller's cap(like emmc) settings.
But, IIRC, you suggested this driver shouldn't be a catchall, and we
now ask the drivers of controllers and phys to take over this, so I
guess we won't put those settings here ever. :)
Thanks for explaining this.
>
> Also settings are pretty individual, so if setting 1 fails, setting 2 can
> still succeed and the boot can continue somewhat farther.
>
sure
> The overall target is supposed to always boot as far as possible, so that
> people might recover or get more information and not fail (and die) early.
>
ok, got it.
>
> Heiko
>
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] ARM: dt: imx31: fix AVIC base address
From: Vladimir Zapolskiy @ 2016-11-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
On i.MX31 AVIC interrupt controller base address is at 0x68000000.
The problem was shadowed by the AVIC driver, which takes the correct
base address from a SoC specific header file.
Fixes: d2a37b3d91f4 ("ARM i.MX31: Add devicetree support")
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
arch/arm/boot/dts/imx31.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index c534c1f..179335b 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -31,11 +31,11 @@
};
};
- avic: avic-interrupt-controller at 60000000 {
+ avic: interrupt-controller at 68000000 {
compatible = "fsl,imx31-avic", "fsl,avic";
interrupt-controller;
#interrupt-cells = <1>;
- reg = <0x60000000 0x100000>;
+ reg = <0x68000000 0x100000>;
};
soc {
--
2.10.2
^ permalink raw reply related
* [PATCH] iommu: mtk: add common-clk dependency
From: Honghui Zhang @ 2016-11-17 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116193850.GK25626@codeaurora.org>
On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote:
> On 11/16, Arnd Bergmann wrote:
> > After the MT2701 clock driver was added, we get a harmless warning for
> > the iommu driver that selects it, when compile-testing without
> > COMMON_CLK.
> >
> > warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK)
> >
> > Adding a dependency on COMMON_CLK avoids the warning.
> >
> > Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hm.. why is an iommu driver selecting a clk driver? They should
> be using standard clk APIs so it's not like they need it for
> build time correctness. Shouldn't we drop the selects instead?
> Those look to have been introduced a few kernel versions ago, but
> they were selecting options that didn't exist until a few days
> ago when I merged the mediatek clk driver. The clk options are
> user-visible, so it should be possible to select them in the
> configuration phase.
>
Hi, Stephen,
I'm a bit out of date of the current clock code. Mediatek IOMMU v1
driver will need smi driver to enable iommu clients. And smi driver is
also respond to enable/disable the susbsys clocks for multi-media HW.
The relationship between iommu and smi is like the graphics below[1].
EMI (External Memory Interface)
|
m4u (Multimedia Memory Management Unit)
|
SMI Common(Smart Multimedia Interface Common)
|
+----------------+-------
| |
| |
SMI larb0 SMI larb1 ... SoCs have several SMI local
arbiter(larb).
(display) (vdec)
| |
| |
+-----+-----+ +----+----+
| | | | | |
| | |... | | | ... There are different ports in each
larb.
| | | | | |
OVL0 RDMA0 WDMA0 MC PP VLD
When enable SMI driver it will need those subsys clock provider.
But those clocks providers are disabled in default. Since it's needed by
smi driver, and smi was select by MTK_IOMMU_V1, I figure it should be
select by MTK_IOMMU_V1 too.
[1]Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
thanks.
> ----8<----
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 8ee54d71c7eb..37e204f3d9be 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -352,9 +352,6 @@ config MTK_IOMMU_V1
> select IOMMU_API
> select MEMORY
> select MTK_SMI
> - select COMMON_CLK_MT2701_MMSYS
> - select COMMON_CLK_MT2701_IMGSYS
> - select COMMON_CLK_MT2701_VDECSYS
> help
> Support for the M4U on certain Mediatek SoCs. M4U generation 1 HW is
> Multimedia Memory Managememt Unit. This option enables remapping of
>
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx: Add ocotp node for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479344899-3141-1-git-send-email-ping.bai@nxp.com>
Add ocotp node for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index c5c05fd..c6f6613 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -849,6 +849,12 @@
reg = <0x021b0000 0x4000>;
};
+ ocotp: ocotp-ctrl at 021bc000 {
+ compatible = "fsl,imx6ul-ocotp", "syscon";
+ reg = <0x021bc000 0x4000>;
+ clocks = <&clks IMX6UL_CLK_OCOTP>;
+ };
+
lcdif: lcdif at 021c8000 {
compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
reg = <0x021c8000 0x4000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] devicetree: bindings: nvmem: Add compatible string for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479344899-3141-1-git-send-email-ping.bai@nxp.com>
Add new compatible string for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
Changes for V2:
- reformat the changes suggested by Rob Herring
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 383d588..966a72e 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -1,13 +1,15 @@
Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
This binding represents the on-chip eFuse OTP controller found on
-i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
+i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
Required properties:
- compatible: should be one of
"fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
"fsl,imx6sl-ocotp" (i.MX6SL), or
- "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
+ "fsl,imx6sx-ocotp" (i.MX6SX),
+ "fsl,imx6ul-ocotp" (i.MX6UL),
+ followed by "syscon".
- reg: Should contain the register base and length.
- clocks: Should contain a phandle pointing to the gated peripheral clock.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/3] driver: nvmem: Add ocotp driver support for imx6ul
From: Bai Ping @ 2016-11-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
i.MX6UL is an new SOC of i.MX6 family. Enable ocotp
driver support for this SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
drivers/nvmem/imx-ocotp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac27b9b..108e4bc 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -73,6 +73,7 @@ static int imx_ocotp_read(void *context, unsigned int offset,
{ .compatible = "fsl,imx6q-ocotp", (void *)128 },
{ .compatible = "fsl,imx6sl-ocotp", (void *)32 },
{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
+ { .compatible = "fsl,imx6ul-ocotp", (void *)128 },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
1.9.1
^ permalink raw reply related
* [PATCH v2] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-17 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdc827c1-f5ba-27b8-b7d0-4489fbd6da28@redhat.com>
On Wed, Nov 16, 2016 at 07:58:26PM +0100, Hans de Goede wrote:
> HI,
>
> On 16-11-16 18:51, Dmitry Torokhov wrote:
> >On Wed, Nov 16, 2016 at 12:55:07PM +0100, Hans de Goede wrote:
> >>On some tablets the touchscreen controller is powered by separate
> >>regulators, add support for this.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>Acked-by: Rob Herring <robh@kernel.org>
> >>---
> >>Changes in v2:
> >>-Use devm_regulator_bulk_get() and friends
> >>-Use devm_add_action_or_reset() to disable the regulator
> >>---
> >> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 ++
> >> drivers/input/touchscreen/silead.c | 29 ++++++++++++++++++++++
> >> 2 files changed, 31 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>index e844c3f..b726823 100644
> >>--- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>+++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> >>@@ -22,6 +22,8 @@ Optional properties:
> >> - touchscreen-inverted-y : See touchscreen.txt
> >> - touchscreen-swapped-x-y : See touchscreen.txt
> >> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> >>+- vddio-supply : regulator phandle for controller VDDIO
> >>+- avdd-supply : regulator phandle for controller AVDD
> >>
> >> Example:
> >>
> >>diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> >>index f502c84..404830a 100644
> >>--- a/drivers/input/touchscreen/silead.c
> >>+++ b/drivers/input/touchscreen/silead.c
> >>@@ -29,6 +29,7 @@
> >> #include <linux/input/touchscreen.h>
> >> #include <linux/pm.h>
> >> #include <linux/irq.h>
> >>+#include <linux/regulator/consumer.h>
> >>
> >> #include <asm/unaligned.h>
> >>
> >>@@ -73,6 +74,7 @@ struct silead_ts_data {
> >> struct i2c_client *client;
> >> struct gpio_desc *gpio_power;
> >> struct input_dev *input;
> >>+ struct regulator_bulk_data regulators[2];
> >> char fw_name[64];
> >> struct touchscreen_properties prop;
> >> u32 max_fingers;
> >>@@ -433,6 +435,13 @@ static int silead_ts_set_default_fw_name(struct silead_ts_data *data,
> >> }
> >> #endif
> >>
> >>+static void silead_disable_regulator(void *arg)
> >>+{
> >>+ struct silead_ts_data *data = arg;
> >>+
> >>+ regulator_bulk_disable(ARRAY_SIZE(data->regulators), data->regulators);
> >>+}
> >>+
> >> static int silead_ts_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >>@@ -465,6 +474,26 @@ static int silead_ts_probe(struct i2c_client *client,
> >> if (client->irq <= 0)
> >> return -ENODEV;
> >>
> >>+ data->regulators[0].supply = "vddio";
> >>+ data->regulators[1].supply = "avdd";
> >>+ error = devm_regulator_bulk_get(dev, ARRAY_SIZE(data->regulators),
> >>+ data->regulators);
> >>+ if (error)
> >>+ return error;
> >>+
> >>+ /*
> >>+ * Enable regulators at probe and disable them at remove, we need
> >>+ * to keep the chip powered otherwise it forgets its firmware.
> >>+ */
> >
> >Hmm, this burns power though. Why can't we reload firmware on resume (it
> >should be already cached)?
>
> We already put the device in low-power mode using the power pin. Of the
> 20 or so different tablets I've with this touchscreen controller only
> 2 actually have a separate regulator for the controller, so I do not
> believe that powering down the regulator will be a big win, otherwise
> all tablets would have had this.
>
> > Does it take too long?
>
> It is a couple of kB written one 32-bit word at a time over i2c, so
> it's not fast.
OK, fair enough. Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Jason Gunthorpe @ 2016-11-16 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611161621260.20443@atull-VirtualBox2>
On Wed, Nov 16, 2016 at 04:28:27PM -0600, atull wrote:
> I agree that this needs a long description and I'm not sure
> why you're pushing back on that.
*shurg* it is just an unusual thing to ask for, but it is OK for a
subsystem to have a particular style like this. Other subsystems
do not.
I will add "This makes the driver prints display properly."
> You will need to rebase this series on linux-next. I won't
> have much time this week to look at this, sorry. Not sure
> what the hurry is. I see the value of this, but things are
> busy right now. I'll be getting up to speed on how the
> kernel does sg and this is kind of a fundamental change to
> the API so I appreciate your patience.
The merge window is opening soon so it would be nice to land some of
this in 4.10.
Since I have to rebase and restructure a chunk of it, I'd like to get
the bulk of the broad feedback collected before doing that..
Jason
^ permalink raw reply
* [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
From: Russell King - ARM Linux @ 2016-11-16 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <592F4D3D062D79449F140027567F70E8FE0810D3@exchmbx03>
On Tue, Nov 15, 2016 at 03:45:55PM +0000, william.helsby at stfc.ac.uk wrote:
> The option of moving the initrd code later (after
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem() )
> was tested.
Moving stuff around tends to break...
I'd prefer to do it this way, as it's much more readable (and we prize
readability... see Documentation/CodingStyle.)
arch/arm/mm/init.c | 71 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..ffae20b25929 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -227,6 +227,48 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
return phys;
}
+static void __init arm_initrd_init(void)
+{
+#ifdef CONFIG_BLK_DEV_INITRD
+ unsigned long size;
+ phys_addr_t start;
+
+ /* FDT scan will populate initrd_start */
+ if (initrd_start && !phys_initrd_size) {
+ phys_initrd_start = __virt_to_phys(initrd_start);
+ phys_initrd_size = initrd_end - initrd_start;
+ }
+
+ initrd_start = initrd_end = 0;
+
+ if (!phys_initrd_size)
+ return;
+
+ start = phys_initrd_start & PAGE_MASK;
+ size = PAGE_ALIGN(phys_initrd_size + phys_initrd_start - start);
+
+ if (!memblock_is_region_memory(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ if (memblock_is_region_reserved(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ memblock_reserve(start, size);
+
+ /* Now convert initrd to virtual addresses */
+ initrd_start = __phys_to_virt(phys_initrd_start);
+ initrd_end = initrd_start + phys_initrd_size;
+#endif
+}
+
void __init arm_memblock_init(const struct machine_desc *mdesc)
{
/* Register the kernel text, kernel data and initrd with memblock. */
@@ -235,34 +277,7 @@ void __init arm_memblock_init(const struct machine_desc *mdesc)
#else
memblock_reserve(__pa(_stext), _end - _stext);
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
- /* FDT scan will populate initrd_start */
- if (initrd_start && !phys_initrd_size) {
- phys_initrd_start = __virt_to_phys(initrd_start);
- phys_initrd_size = initrd_end - initrd_start;
- }
- initrd_start = initrd_end = 0;
- if (phys_initrd_size &&
- !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size &&
- memblock_is_region_reserved(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size) {
- memblock_reserve(phys_initrd_start, phys_initrd_size);
-
- /* Now convert initrd to virtual addresses */
- initrd_start = __phys_to_virt(phys_initrd_start);
- initrd_end = initrd_start + phys_initrd_size;
- }
-#endif
-
+ arm_initrd_init();
arm_mm_memblock_reserve();
/* reserve any platform specific memblock areas */
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH v3 3/3] ARM: rockchip: drop rk3288 jtag/mmc switch handling
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
We moved that functionality to a more generic place where it can also
be used for other socs, so drop it from architecture code.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
arch/arm/mach-rockchip/rockchip.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c
index e7fdf06..0008783 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -29,13 +29,11 @@
#include "core.h"
#include "pm.h"
-#define RK3288_GRF_SOC_CON0 0x244
#define RK3288_TIMER6_7_PHYS 0xff810000
static void __init rockchip_timer_init(void)
{
if (of_machine_is_compatible("rockchip,rk3288")) {
- struct regmap *grf;
void __iomem *reg_base;
/*
@@ -54,16 +52,6 @@ static void __init rockchip_timer_init(void)
} else {
pr_err("rockchip: could not map timer7 registers\n");
}
-
- /*
- * Disable auto jtag/sdmmc switching that causes issues
- * with the mmc controllers making them unreliable
- */
- grf = syscon_regmap_lookup_by_compatible("rockchip,rk3288-grf");
- if (!IS_ERR(grf))
- regmap_write(grf, RK3288_GRF_SOC_CON0, 0x10000000);
- else
- pr_err("rockchip: could not get grf syscon\n");
}
of_clk_init(NULL);
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
The General Register Files are an area of registers containing a lot
of single-bit settings for numerous components as well full components
like usbphy control. Therefore all used components are accessed
via the syscon provided by the grf nodes or from the sub-devices
created through the simple-mfd created from the grf node.
Some settings are not used by anything but will need to be set up
according to expectations on the kernel side.
Best example is the force_jtag setting, which defaults to on and
results in the soc switching the pin-outputs between jtag and sdmmc
automatically depending on the card-detect status. This conflicts
heavily with how the dw_mmc driver expects to do its work and also
with the clock-controller, which has most likely deactivated the
jtag clock due to it being unused.
So far the handling of this setting was living in the mach-rockchip
code for the arm32-based rk3288 but that of course doesn't work
for arm64 socs and would also look ugly for further arm32 socs.
Also always disabling this setting is quite specific to linux and
its subsystems, other operating systems might prefer other settings,
so that the bootloader cannot really set a sane default for all.
So introduce a top-level driver for the grf that handles these
settings that need to be a certain way but nobody cares about.
Other needed settings might surface in the future and can then
be added here, but only as a last option. Ideally general GRF
settings should be handled in the driver needing them.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---
drivers/soc/rockchip/Kconfig | 10 ++++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 133 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 144 insertions(+)
create mode 100644 drivers/soc/rockchip/grf.c
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
index 7140ff8..20da55d 100644
--- a/drivers/soc/rockchip/Kconfig
+++ b/drivers/soc/rockchip/Kconfig
@@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
#
# Rockchip Soc drivers
#
+
+config ROCKCHIP_GRF
+ bool
+ default y
+ help
+ The General Register Files are a central component providing
+ special additional settings registers for a lot of soc-components.
+ In a lot of cases there also need to be default settings initialized
+ to make some of them conform to expectations of the kernel.
+
config ROCKCHIP_PM_DOMAINS
bool "Rockchip generic power domain"
depends on PM
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
index 3d73d06..c851fa0 100644
--- a/drivers/soc/rockchip/Makefile
+++ b/drivers/soc/rockchip/Makefile
@@ -1,4 +1,5 @@
#
# Rockchip Soc drivers
#
+obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
new file mode 100644
index 0000000..190b0ed
--- /dev/null
+++ b/drivers/soc/rockchip/grf.c
@@ -0,0 +1,134 @@
+/*
+ * Rockchip Generic Register Files setup
+ *
+ * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define HIWORD_UPDATE(val, mask, shift) \
+ ((val) << (shift) | (mask) << ((shift) + 16))
+
+struct rockchip_grf_value {
+ const char *desc;
+ u32 reg;
+ u32 val;
+};
+
+struct rockchip_grf_info {
+ const struct rockchip_grf_value *values;
+ int num_values;
+};
+
+#define RK3036_GRF_SOC_CON0 0x140
+
+static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
+ /*
+ * Disable auto jtag/sdmmc switching that causes issues with the
+ * clock-framework and the mmc controllers making them unreliable.
+ */
+ { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
+};
+
+static const struct rockchip_grf_info rk3036_grf __initconst = {
+ .values = rk3036_defaults,
+ .num_values = ARRAY_SIZE(rk3036_defaults),
+};
+
+#define RK3288_GRF_SOC_CON0 0x244
+
+static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
+ { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3288_grf __initconst = {
+ .values = rk3288_defaults,
+ .num_values = ARRAY_SIZE(rk3288_defaults),
+};
+
+#define RK3368_GRF_SOC_CON15 0x43c
+
+static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
+ { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
+};
+
+static const struct rockchip_grf_info rk3368_grf __initconst = {
+ .values = rk3368_defaults,
+ .num_values = ARRAY_SIZE(rk3368_defaults),
+};
+
+#define RK3399_GRF_SOC_CON7 0xe21c
+
+static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
+ { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
+};
+
+static const struct rockchip_grf_info rk3399_grf __initconst = {
+ .values = rk3399_defaults,
+ .num_values = ARRAY_SIZE(rk3399_defaults),
+};
+
+static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
+ {
+ .compatible = "rockchip,rk3036-grf",
+ .data = (void *)&rk3036_grf,
+ }, {
+ .compatible = "rockchip,rk3288-grf",
+ .data = (void *)&rk3288_grf,
+ }, {
+ .compatible = "rockchip,rk3368-grf",
+ .data = (void *)&rk3368_grf,
+ }, {
+ .compatible = "rockchip,rk3399-grf",
+ .data = (void *)&rk3399_grf,
+ },
+ { /* sentinel */ },
+};
+
+static int __init rockchip_grf_init(void)
+{
+ const struct rockchip_grf_info *grf_info;
+ const struct of_device_id *match;
+ struct device_node *np;
+ struct regmap *grf;
+ int ret, i;
+
+ np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match,
+ &match);
+ if (!np)
+ return -ENODEV;
+ if (!match || !match->data) {
+ pr_err("%s: missing grf data\n", __func__);
+ return -EINVAL;
+ }
+
+ grf_info = match->data;
+
+ grf = syscon_node_to_regmap(np);
+ if (IS_ERR(grf)) {
+ pr_err("%s: could not get grf syscon\n", __func__);
+ return PTR_ERR(grf);
+ }
+
+ for (i = 0; i < grf_info->num_values; i++) {
+ const struct rockchip_grf_value *val = &grf_info->values[i];
+
+ pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
+ val->desc, val->reg, val->val);
+ ret = regmap_write(grf, val->reg, val->val);
+ if (ret < 0)
+ pr_err("%s: write to %#6x failed with %d\n",
+ __func__, val->reg, ret);
+ }
+
+ return 0;
+}
+postcore_initcall(rockchip_grf_init);
--
2.10.2
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: add used but undocumented rockchip grf compatible values
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
There are some more General Register Files used in devicetree files
already, but as of now undocumented in the binding document, fix that.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/grf.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
index 013e71a..c6e62cb 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -5,11 +5,13 @@ is composed of many registers for system control.
From RK3368 SoCs, the GRF is divided into two sections,
- GRF, used for general non-secure system,
+- SGRF, used for general secure system,
- PMUGRF, used for always on system
Required Properties:
- compatible: GRF should be one of the followings
+ - "rockchip,rk3036-grf", "syscon": for rk3036
- "rockchip,rk3066-grf", "syscon": for rk3066
- "rockchip,rk3188-grf", "syscon": for rk3188
- "rockchip,rk3228-grf", "syscon": for rk3228
@@ -19,6 +21,8 @@ Required Properties:
- compatible: PMUGRF should be one of the followings
- "rockchip,rk3368-pmugrf", "syscon": for rk3368
- "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- compatible: SGRF should be one of the following
+ - "rockchip,rk3288-sgrf", "syscon": for rk3288
- reg: physical base address of the controller and length of memory mapped
region.
--
2.10.2
^ permalink raw reply related
* [PATCH v3 0/3] Rockchip: generalize GRF setup
From: Heiko Stuebner @ 2016-11-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
The General register files contain a big bunch of settings for various
components. Things like the automatic sdmmc/jtag switch may even affect
us in a bad way, while that property (and possibly others) are not even
part of the dw_mmc controller itself.
And while the rk3288 could still carry adaptions to these defaults
in its mach files, this is no longer possible on the arm64 socs, while
things like the jtag-switch from above still can affect us there.
changes in v3:
- remove duplicate regmap header (now they're even sorted alphabetically)
- add Dougs Review-tag from v2
- fix the of_find_matching_node_and_match being over 80 chars
changes in v2:
- address comments from Doug Anderson
- drop platform device, as we actual probing may happen at some
unspecified later time during boot
- add reviews / acks received in v1
Heiko Stuebner (3):
dt-bindings: add used but undocumented rockchip grf compatible values
soc: rockchip: add driver handling grf setup
ARM: rockchip: drop rk3288 jtag/mmc switch handling
.../devicetree/bindings/soc/rockchip/grf.txt | 4 +
arch/arm/mach-rockchip/rockchip.c | 12 --
drivers/soc/rockchip/Kconfig | 10 ++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/grf.c | 133 +++++++++++++++++++++
5 files changed, 148 insertions(+), 12 deletions(-)
create mode 100644 drivers/soc/rockchip/grf.c
--
2.10.2
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Fabio Estevam @ 2016-11-16 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116224024.GA11821@roeck-us.net>
On Wed, Nov 16, 2016 at 8:40 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Yes, but not the 'device_type' property, which the kernel seems to expect.
> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.
I can send the patch adding device_type for the i.MX dts files, but in
the meantime, it would be nice if you could send your proposal patch
to qemu as it will make qemu to work closer to the real hardware.
Thanks
> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.
We can fix this too in the dts.
Thanks
^ permalink raw reply
* [PATCH] net: bcm63xx_enet: fix build failure
From: David Miller @ 2016-11-16 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479336616-26500-1-git-send-email-sudipm.mukherjee@gmail.com>
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Wed, 16 Nov 2016 22:50:16 +0000
> The build of mips bcm63xx_defconfig was failing with the error:
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
> error: expected expression before 'return'
>
> The return statement should be termibated with ';' and not ','.
>
> Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Already fixes in the current net-next tree.
^ permalink raw reply
* [PATCH] net: bcm63xx_enet: fix build failure
From: Sudip Mukherjee @ 2016-11-16 22:50 UTC (permalink / raw)
To: linux-arm-kernel
The build of mips bcm63xx_defconfig was failing with the error:
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1440:2:
error: expected expression before 'return'
The return statement should be termibated with ';' and not ','.
Fixes: 42469bf5d9bb ("net: bcm63xx_enet: Utilize phy_ethtool_nway_reset")
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
build log is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/176269457
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a43ab90..3b14d51 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1435,7 +1435,7 @@ static int bcm_enet_nway_reset(struct net_device *dev)
priv = netdev_priv(dev);
if (priv->has_phy)
- return phy_ethtool_nway_reset(dev),
+ return phy_ethtool_nway_reset(dev);
return -EOPNOTSUPP;
}
--
1.9.1
^ permalink raw reply related
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Moritz Fischer @ 2016-11-16 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611161621260.20443@atull-VirtualBox2>
Hi Jason,
On Wed, Nov 16, 2016 at 2:28 PM, atull <atull@opensource.altera.com> wrote:
> On Wed, 16 Nov 2016, Jason Gunthorpe wrote:
>
>> On Wed, Nov 16, 2016 at 10:39:26AM -0800, Moritz Fischer wrote:
>> > > As you say, it is crystal clear already, and this is an acceptable commit
>> > > message.. Please suggest a text if you want to see something
>> > > different.
>> > >
>> >
>> > It still needs a long message. Just do it.
>>
>> Can I put your reviewed-by on this when I resend the series?
For this particular patch, feel free to add my Reviewed-By: after fixing
the long description. As Alan said there's currently a lot of patches
in flight and we're working on coming up with a better workflow.
Stay tuned.
>>
>> Will you have time to review the other patches this week?
>>
>> Jason
>>
>
> Hi Jason,
>
> I agree that this needs a long description and I'm not sure
> why you're pushing back on that.
>
> You will need to rebase this series on linux-next. I won't
> have much time this week to look at this, sorry. Not sure
> what the hurry is. I see the value of this, but things are
> busy right now. I'll be getting up to speed on how the
> kernel does sg and this is kind of a fundamental change to
> the API so I appreciate your patience.
Same here. We'll get prototypes next week, so I'm busy this week
and next week. I agree there's no massive hurry.
Thanks,
Moritz
^ permalink raw reply
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