* [PATCH] ARM: DTS: dra7: fix DCAN node addresses
From: Tony Lindgren @ 2018-05-23 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf431fca-0372-bd50-88e7-d478e4aa52da@ti.com>
* Roger Quadros <rogerq@ti.com> [180521 20:25]:
> On 21/05/18 15:08, Kevin Hilman wrote:
> > Fix the DT node addresses to match the reg property addresses,
> > which were verified to match the TRM:
> > http://www.ti.com/lit/pdf/sprui30
> >
> > Cc: Roger Quadros <rogerq@ti.com>
> > Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>
> Thanks Kevin.
>
> Acked-by: Roger Quadros <rogerq@ti.com>
Applying into omap-for-v4.18/dt-fixes thanks.
Tony
^ permalink raw reply
* [PATCH V4 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-23 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527090479-5263-9-git-send-email-christophe.roullier@st.com>
On Wed, May 23, 2018 at 05:47:59PM +0200, Christophe Roullier wrote:
> This patch describes syscon DT bindings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 10 ----------
> .../devicetree/bindings/arm/stm32/stm32-syscon.txt | 14 ++++++++++++++
> Documentation/devicetree/bindings/arm/stm32/stm32.txt | 10 ++++++++++
> 3 files changed, 24 insertions(+), 10 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
> create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
> create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt
In the future, use the -M option so file moves don't show any diff.
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/5] add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
drivers/pci/hotplug/pnv_php.c | 8 ++++++--
drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 9 +++++++--
drivers/pinctrl/pinctrl-at91-pio4.c | 4 +++-
drivers/soc/ti/knav_dma.c | 1 +
5 files changed, 20 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/5] pinctrl: at91-pio4: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/pinctrl/pinctrl-at91-pio4.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index 4b57a13..bafb3d4 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -576,8 +576,10 @@ static int atmel_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
for_each_child_of_node(np_config, np) {
ret = atmel_pctl_dt_subnode_to_map(pctldev, np, map,
&reserved_maps, num_maps);
- if (ret < 0)
+ if (ret < 0) {
+ of_node_put(np);
break;
+ }
}
}
^ permalink raw reply related
* [PATCH 3/5] soc: ti: knav_dma: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/soc/ti/knav_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 224d7dd..bda3173 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -768,6 +768,7 @@ static int knav_dma_probe(struct platform_device *pdev)
ret = dma_init(node, child);
if (ret) {
dev_err(&pdev->dev, "init failed with %d\n", ret);
+ of_node_put(child);
break;
}
}
^ permalink raw reply related
* [PATCH 5/5] drm/rockchip: lvds: add missing of_node_put
From: Julia Lawall @ 2018-05-23 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527102436-13447-1-git-send-email-Julia.Lawall@lip6.fr>
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index e67f4ea..051b8be 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -363,8 +363,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
of_property_read_u32(endpoint, "reg", &endpoint_id);
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, endpoint_id,
&lvds->panel, &lvds->bridge);
- if (!ret)
+ if (!ret) {
+ of_node_put(endpoint);
break;
+ }
}
if (!child_count) {
DRM_DEV_ERROR(dev, "lvds port does not have any children\n");
^ permalink raw reply related
* [GIT PULL] pinctrl: samsung: Stuff for v4.18 (second version)
From: Krzysztof Kozlowski @ 2018-05-23 19:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
This is updated pull request with one additional patch from Marek.
I saw you did not pull my previous pull request for v4.18 so I hope
this update should not be a problem.
Anyway it is on top of previous request (no rebase) so it can be also
applied incrementally.
Best regards,
Krzysztof
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git tags/samsung-pinctrl-4.18-2
for you to fetch changes up to 7c24e71c8a6423dfa5a7f19b253726b23af0c507:
pinctrl: samsung: Fix suspend/resume for Exynos5433 GPF1..5 banks (2018-05-23 21:23:19 +0200)
----------------------------------------------------------------
Samsung pinctrl drivers changes for v4.18
1. Driver expects specific order of GPIO interrupt banks. For S5Pv220
and Exynos5410 this order was not preserved so fix and document it.
2. Remove support for Exynos5440 (tree-wide, support is dropped because
there are no real users of this platform, it also did not get testing
since long time).
3. Fix lost state of GPF1..5 pins on Exynos5433 during system suspend.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
pinctrl: samsung: Remove support for Exynos5440
Marek Szyprowski (1):
pinctrl: samsung: Fix suspend/resume for Exynos5433 GPF1..5 banks
Pawe? Chmiel (2):
pinctrl: samsung: Correct EINTG banks order
pinctrl: samsung: Document required order of banks
drivers/pinctrl/samsung/Kconfig | 10 +-
drivers/pinctrl/samsung/Makefile | 1 -
drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 30 +-
drivers/pinctrl/samsung/pinctrl-exynos-arm64.c | 20 +
drivers/pinctrl/samsung/pinctrl-exynos.h | 2 +-
drivers/pinctrl/samsung/pinctrl-exynos5440.c | 1005 ------------------------
6 files changed, 51 insertions(+), 1017 deletions(-)
delete mode 100644 drivers/pinctrl/samsung/pinctrl-exynos5440.c
^ permalink raw reply
* [PATCH net] net: phy: broadcom: Fix bcm_write_exp()
From: David Miller @ 2018-05-23 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523000450.9384-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 22 May 2018 17:04:49 -0700
> On newer PHYs, we need to select the expansion register to write with
> setting bits [11:8] to 0xf. This was done correctly by bcm7xxx.c prior
> to being migrated to generic code under bcm-phy-lib.c which
> unfortunately used the older implementation from the BCM54xx days.
>
> Fix this by creating an inline stub: bcm_write_exp_sel() which adds the
> correct value (MII_BCM54XX_EXP_SEL_ER) and update both the Cygnus PHY
> and BCM7xxx PHY drivers which require setting these bits.
>
> broadcom.c is unchanged because some PHYs even use a different selector
> method, so let them specify it directly (e.g: SerDes secondary selector).
>
> Fixes: a1cba5613edf ("net: phy: Add Broadcom phy library for common interfaces")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David, please also queue this one up for -stable, thanks!
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Ray Jui @ 2018-05-23 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523185944.GA9989@rob-hp-laptop>
On 5/23/2018 11:59 AM, Rob Herring wrote:
> On Wed, May 23, 2018 at 09:25:49AM -0700, Ray Jui wrote:
>>
>>
>> On 5/23/2018 3:57 AM, Robin Murphy wrote:
>>> On 22/05/18 19:47, Ray Jui wrote:
>>>> Update the SP805 binding document to add optional 'timeout-sec'
>>>> devicetree property
>>>>
>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>>>> ? Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
>>>> ? 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>> b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>> index edc4f0e..f898a86 100644
>>>> --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>> @@ -19,6 +19,8 @@ Required properties:
>>>> ? Optional properties:
>>>> ? - interrupts : Should specify WDT interrupt number.
>>>> +- timeout-sec : Should specify default WDT timeout in seconds. If
>>>> unset, the
>>>> +??????????????? default timeout is 30 seconds
>>>
>>> According to the SP805 TRM, the default interval is dependent on the
>>> rate of WDOGCLK, but would typically be a lot longer than that :/
>>>
>>> On a related note, anyone have any idea why we seem to have two subtly
>>> different SP805 bindings defined?
>
> Sigh.
>
>> Interesting, I did not even know that until you pointed this out (and it's
>> funny that I found that I actually reviewed arm,sp805.txt internally in
>> Broadcom code review).
>>
>> It looks like one was done by Bhupesh Sharma (sp805-wdt.txt) and the other
>> was done by Anup Patel (arm,sp805.txt). Both were merged at the same time
>> around March 20, 2016: 915c56bc01d6. I'd assume both were sent out at around
>> the same time.
>>
>> It sounds like we should definitely remove one of them. Given that
>> sp805-wdt.txt appears to have more detailed descriptions on the use of the
>> clocks, should we remove arm,sp805.txt?
>
> Take whichever text you like, but I prefer filenames using the
> compatible string and the correct string is 'arm,sp805' because '-wdt'
> is redundant. You can probably safely just update all the dts files with
> 'arm,sp805' and just remove 'arm,sp805-wdt' because it is not actually
> used (as the ID registers are).
Okay. I'll consolidate everything into arm,sp805.txt. Will also fix all
DTS files to use "arm,sp805". The fix for actual DTS files will be in a
different patch series.
>
> Rob
>
^ permalink raw reply
* [PATCH v10 05/18] KVM: arm64: Convert lazy FPSIMD context switch trap to C
From: Alex Bennée @ 2018-05-23 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527005119-6842-6-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> To make the lazy FPSIMD context switch trap code easier to hack on,
> this patch converts it to C.
>
> This is not amazingly efficient, but the trap should typically only
> be taken once per host context switch.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kvm/hyp/entry.S | 57 +++++++++++++++++----------------------------
> arch/arm64/kvm/hyp/switch.c | 24 +++++++++++++++++++
> 2 files changed, 46 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index e41a161..40f349b 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -172,40 +172,27 @@ ENTRY(__fpsimd_guest_restore)
> // x1: vcpu
> // x2-x29,lr: vcpu regs
> // vcpu x0-x1 on the stack
> - stp x2, x3, [sp, #-16]!
> - stp x4, lr, [sp, #-16]!
> -
> -alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
> - mrs x2, cptr_el2
> - bic x2, x2, #CPTR_EL2_TFP
> - msr cptr_el2, x2
> -alternative_else
> - mrs x2, cpacr_el1
> - orr x2, x2, #CPACR_EL1_FPEN
> - msr cpacr_el1, x2
> -alternative_endif
> - isb
> -
> - mov x3, x1
> -
> - ldr x0, [x3, #VCPU_HOST_CONTEXT]
> - kern_hyp_va x0
> - add x0, x0, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> - bl __fpsimd_save_state
> -
> - add x2, x3, #VCPU_CONTEXT
> - add x0, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> - bl __fpsimd_restore_state
> -
> - // Skip restoring fpexc32 for AArch64 guests
> - mrs x1, hcr_el2
> - tbnz x1, #HCR_RW_SHIFT, 1f
> - ldr x4, [x3, #VCPU_FPEXC32_EL2]
> - msr fpexc32_el2, x4
> -1:
> - ldp x4, lr, [sp], #16
> - ldp x2, x3, [sp], #16
> - ldp x0, x1, [sp], #16
> -
> + stp x2, x3, [sp, #-144]!
> + stp x4, x5, [sp, #16]
> + stp x6, x7, [sp, #32]
> + stp x8, x9, [sp, #48]
> + stp x10, x11, [sp, #64]
> + stp x12, x13, [sp, #80]
> + stp x14, x15, [sp, #96]
> + stp x16, x17, [sp, #112]
> + stp x18, lr, [sp, #128]
> +
> + bl __hyp_switch_fpsimd
> +
> + ldp x4, x5, [sp, #16]
> + ldp x6, x7, [sp, #32]
> + ldp x8, x9, [sp, #48]
> + ldp x10, x11, [sp, #64]
> + ldp x12, x13, [sp, #80]
> + ldp x14, x15, [sp, #96]
> + ldp x16, x17, [sp, #112]
> + ldp x18, lr, [sp, #128]
> + ldp x0, x1, [sp, #144]
> + ldp x2, x3, [sp], #160
> eret
> ENDPROC(__fpsimd_guest_restore)
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index d964523..c0796c4 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -318,6 +318,30 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> }
> }
>
> +void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> + struct kvm_vcpu *vcpu)
> +{
> + kvm_cpu_context_t *host_ctxt;
> +
> + if (has_vhe())
> + write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> + cpacr_el1);
> + else
> + write_sysreg(read_sysreg(cptr_el2) & ~(u64)CPTR_EL2_TFP,
> + cptr_el2);
Is there no way to do alternative() in C or does it always come down to
different inline asms?
Anyway:
Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
> +
> + isb();
> +
> + host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> + __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> + __fpsimd_restore_state(&vcpu->arch.ctxt.gp_regs.fp_regs);
> +
> + /* Skip restoring fpexc32 for AArch64 guests */
> + if (!(read_sysreg(hcr_el2) & HCR_RW))
> + write_sysreg(vcpu->arch.ctxt.sys_regs[FPEXC32_EL2],
> + fpexc32_el2);
> +}
> +
> /*
> * Return true when we were able to fixup the guest exit and should return to
> * the guest, false when we should restore the host state and return to the
--
Alex Benn?e
^ permalink raw reply
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Ray Jui @ 2018-05-23 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523180920.GB27570@roeck-us.net>
Hi Guenter/Robin,
On 5/23/2018 11:09 AM, Guenter Roeck wrote:
> On Wed, May 23, 2018 at 06:15:14PM +0100, Robin Murphy wrote:
>> On 23/05/18 17:29, Ray Jui wrote:
>>> Hi Robin,
>>>
>>> On 5/23/2018 4:48 AM, Robin Murphy wrote:
>>>> On 23/05/18 08:52, Scott Branden wrote:
>>>>>
>>>>>
>>>>> On 18-05-22 04:24 PM, Ray Jui wrote:
>>>>>> Hi Guenter,
>>>>>>
>>>>>> On 5/22/2018 1:54 PM, Guenter Roeck wrote:
>>>>>>> On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
>>>>>>>> If the watchdog hardware is already enabled during the boot process,
>>>>>>>> when the Linux watchdog driver loads, it should reset the
>>>>>>>> watchdog and
>>>>>>>> tell the watchdog framework. As a result, ping can be generated from
>>>>>>>> the watchdog framework, until the userspace watchdog daemon
>>>>>>>> takes over
>>>>>>>> control
>>>>>>>>
>>>>>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>>>>>> Reviewed-by: Vladimir Olovyannikov
>>>>>>>> <vladimir.olovyannikov@broadcom.com>
>>>>>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>>>>>> ---
>>>>>>>> ? drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
>>>>>>>> ? 1 file changed, 22 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/watchdog/sp805_wdt.c
>>>>>>>> b/drivers/watchdog/sp805_wdt.c
>>>>>>>> index 1484609..408ffbe 100644
>>>>>>>> --- a/drivers/watchdog/sp805_wdt.c
>>>>>>>> +++ b/drivers/watchdog/sp805_wdt.c
>>>>>>>> @@ -42,6 +42,7 @@
>>>>>>>> ????? /* control register masks */
>>>>>>>> ????? #define??? INT_ENABLE??? (1 << 0)
>>>>>>>> ????? #define??? RESET_ENABLE??? (1 << 1)
>>>>>>>> +??? #define??? ENABLE_MASK??? (INT_ENABLE | RESET_ENABLE)
>>>>>>>> ? #define WDTINTCLR??????? 0x00C
>>>>>>>> ? #define WDTRIS??????????? 0x010
>>>>>>>> ? #define WDTMIS??????????? 0x014
>>>>>>>> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
>>>>>>>> ? MODULE_PARM_DESC(nowayout,
>>>>>>>> ????????? "Set to 1 to keep watchdog running after device release");
>>>>>>>> ? +/* returns true if wdt is running; otherwise returns false */
>>>>>>>> +static bool wdt_is_running(struct watchdog_device *wdd)
>>>>>>>> +{
>>>>>>>> +??? struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>>>>>>> +
>>>>>>>> +??? if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
>>>>>>>> +??????? ENABLE_MASK)
>>>>>>>> +??????? return true;
>>>>>>>> +??? else
>>>>>>>> +??????? return false;
>>>>>>>
>>>>>>> ????return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>>>>>>
>>>>>>
>>>>>> Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
>>>>>> therefore, a simple !!(expression) would not work? That is, the
>>>>>> masked result needs to be compared against the mask again to ensure
>>>>>> both bits are set, right?
>>>>> Ray - your original code looks correct to me.? Easier to read and less
>>>>> prone to errors as shown in the attempted translation to a single
>>>>> statement.
>>>>
>>>> ?????if (<boolean condition>)
>>>> ???????? return true;
>>>> ?????else
>>>> ???????? return false;
>>>>
>>>> still looks really dumb, though, and IMO is actually harder to read than
>>>> just "return <boolean condition>;" because it forces you to stop and
>>>> double-check that the logic is, in fact, only doing the obvious thing.
>>>
>>> If you can propose a way to modify my original code above to make it more
>>> readable, I'm fine to make the change.
>>
>> Well,
>>
>> return readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK == ENABLE_MASK;
>>
>> would probably be reasonable to anyone other than the 80-column zealots, but
>> removing the silly boolean-to-boolean translation idiom really only
>> emphasises the fact that it's fundamentally a big complex statement; for
>> maximum clarity I'd be inclined to separate the two logical operations (read
>> and comparison), e.g.:
>>
>> u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
>>
>> return wdtcontrol & ENABLE_MASK == ENABLE_MASK;
>
> == has higher precendence than bitwise &, so this will need ( ),
> but otherwise I agree.
>
Sure. Let me change the code to the following:
u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
return (wdtcontrol & ENABLE_MASK) == ENABLE_MASK;
Thanks.
Ray
>>
>> which is still -3 lines vs. the original.
>>
>>> As I mentioned, I don't think the following change proposed by Guenter
>>> will work due to the reason I pointed out:
>>>
>>> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>
>> FWIW, getting the desired result should only need one logical not swapping
>> for a bitwise one there:
>>
>> return !(~readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK);
>>
>> but that's well into "too clever for its own good" territory ;)
>
> Yes, that would be confusing.
>
>>
>> Robin.
^ permalink raw reply
* [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Laurent Pinchart @ 2018-05-23 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523162947.GA13661@rob-hp-laptop>
Hi Rob,
On Wednesday, 23 May 2018 19:29:47 EEST Rob Herring wrote:
> On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> > Describe the optional endpoint properties for endpoint nodes of port at 0
> > and port at 1 of the R-Car VIN driver device tree bindings documentation.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> > a19517e1..c53ce4e 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on
> > SoC.
> >
> > from external SoC pins described in video-interfaces.txt[1].
> > Describing more then one endpoint in port 0 is invalid. Only VIN
> > instances that are connected to external pins should have port 0.
> >
> > +
> > + - Optional properties for endpoint nodes of port at 0:
> > + - hsync-active: active state of the HSYNC signal, 0/1 for
> > LOW/HIGH
> > + respectively. Default is active high.
> > + - vsync-active: active state of the VSYNC signal, 0/1 for
> > LOW/HIGH
> > + respectively. Default is active high.
> > +
> > + If both HSYNC and VSYNC polarities are not specified, embedded
> > + synchronization is selected.
>
> No need to copy-n-paste from video-interfaces.txt. Just "see
> video-interfaces.txt" for the description is fine.
I would still explicitly list the properties that apply to this binding. I
agree that there's no need to copy & paste the description of those properties
though.
> > +
> >
> > - port 1 - sub-nodes describing one or more endpoints connected to
> >
> > the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> > use the following schema.
> >
> > @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> >
> > - Endpoint 2 - sub-node describing the endpoint connected to
> > CSI40
> > - Endpoint 3 - sub-node describing the endpoint connected to
> > CSI41
> >
> > + Endpoint nodes of port at 1 do not support any optional endpoint
> > property. +
> >
> > Device node example for Gen2 platforms
> > --------------------------------------
> >
> > @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite
> > video input)>
> > vin1ep0: endpoint {
> >
> > remote-endpoint = <&adv7180>;
> >
> > - bus-width = <8>;
> >
> > };
> >
> > };
> >
> > };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Russell King - ARM Linux @ 2018-05-23 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35edb3df-fed4-b6e6-be0c-ee758618c92e@arm.com>
On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
> On 21/05/18 12:45, Russell King wrote:
> > +#ifdef CONFIG_ARM_PSCI
> > + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
> > + struct arm_smccc_res res;
> > +
> > + switch (psci_ops.conduit) {
> > + case PSCI_CONDUIT_HVC:
> > + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> > + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> > + if ((int)res.a0 < 0)
> > + break;
>
> I just realised that there is a small, but significant difference
> between this and the arm64 version: On arm64, we have a table of
> vulnerable implementations, and we try the mitigation on a per-cpu
> basis. Here, you entirely rely on the firmware to discover whether the
> CPU needs mitigation or not. You then need to check for a return value
> of 1, which indicates that although the mitigation is implemented, it is
> not required on this particular CPU.
Okay, so digging further into the documentation seems to suggest that we
only need to check the firmware for A72 and A57 CPUs, and given this
statement:
"Arm recommends that the caller only call this on PEs for which a
firmware based mitigation of CVE-2017-5715 is required, or where
a local workaround is infeasible."
it seems that the right answer is to ignore the PSCI based methods when
we have anything but these CPUs. Do you agree?
> But that's probably moot if you don't support BL systems.
Any bL systems with A72 or A57?
--
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 1/6] coresight: remove CORESIGHT_LINKS_AND_SINKS dependencies and selections
From: Kim Phillips @ 2018-05-23 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522173140.GA25658@xps15>
On Tue, 22 May 2018 11:31:40 -0600
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Thu, May 17, 2018 at 08:20:19PM -0500, Kim Phillips wrote:
> > A coresight topology doesn't need to include links, i.e., a source can
> > be directly connected to a sink. As such, selecting and/or depending on
> > LINKS_AND_SINKS is no longer needed.
>
> I'm good with this patch but now the help text for CORESIGHT_LINKS_AND_SINKS no
> longer match what the config does. I see two ways to fix this:
This patch doesn't change what the config does, it just changes what
other config options depend on it.
> 1) Rework the help text.
I don't see how, given the above. Here's the text:
config CORESIGHT_LINKS_AND_SINKS
bool "CoreSight Link and Sink drivers"
help
This enables support for CoreSight link and sink drivers that are
responsible for transporting and collecting the trace data
respectively. Link and sinks are dynamically aggregated with a trace
entity at run time to form a complete trace path.
What part of that becomes invalid with this patch?
> 2) Rework CORESIGHT_LINKS_AND_SINKS to be CORESIGHT_FUNNEL and move
> coresight-replicator.o under CORESIGHT_DYNAMIC_REPLICATOR in the Makefile. I
> really liked your idea of making the replicator driver intelligent enough to
> deal with both DT and platform declaration, which merges two driver into one.
>
> I'm obviously favouring the second option but recognise it doesn't have to be
> part of this patchet. So for this set please rework the help text for
> CORESIGHT_LINKS_AND_SINKS. Once we've dealt with this topic we can refactor the
> replicator driver.
I'd really like to just focus on getting CoreSight to load as modules,
something for which this patch isn't technically required...
Thanks,
Kim
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-23 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1685755.J6GI985WX3@diego>
On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
> Hi Rob, Levin,
>
> sorry for being late to the party.
>
> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>> > On 2018-05-23 2:02 AM, Rob Herring wrote:
>> >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>> >>> From: Levin Du <djw@t-chip.com.cn>
>> >>>
>> >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>> >>> which do not belong to the general pinctrl.
>> >>>
>> >>> Adding gpio-syscon support makes controlling regulator or
>> >>> LED using these special pins very easy by reusing existing
>> >>> drivers, such as gpio-regulator and led-gpio.
>> >>>
>> >>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>> >>>
>> >>> ---
>> >>>
>> >>> Changes in v2:
>> >>> - Rename gpio_syscon10 to gpio_mute in doc
>> >>>
>> >>> Changes in v1:
>> >>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>> >>> - Add doc rockchip,gpio-syscon.txt
>> >>>
>> >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>> >>>
>> >>> ++++++++++++++++++++++
>> >>>
>> >>> drivers/gpio/gpio-syscon.c | 30
>> >>>
>> >>> ++++++++++++++++
>> >>>
>> >>> 2 files changed, 71 insertions(+)
>> >>> create mode 100644
>> >>>
>> >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >>> new file mode 100644
>> >>> index 0000000..b1b2a67
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >>> @@ -0,0 +1,41 @@
>> >>> +* Rockchip GPIO support for GRF_SOC_CON registers
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: Should contain "rockchip,gpio-syscon".
>> >>> +- 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.
>> >>
>> >> There's no need for this child node. Just make the parent node a gpio
>> >> controller.
>> >>
>> >> Rob
>> >
>> > Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>> > a
>> > gpio controller,
>> > like below?
>> >
>> > + grf: syscon at ff100000 {
>> > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>> > "syscon", "simple-mfd";
>>
>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>
> I would disagree quite a bit here. The grf are the "general register files",
> a bunch of registers used for quite a lot of things, and so it seems
> among other users, also a gpio-controller for some more random pins
> not controlled through the regular gpio controllers.
>
> For a more fully stocked grf, please see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>
> So the gpio controller should definitly also be a subnode.
Sigh, yes, if there are a bunch of functions needing subnodes like the
above, then yes that makes sense. But that's not what has been
presented. Please make some attempt at defining *all* the functions.
An actual binding would be nice, but I'll settle for just a list of
things. The list should have functions that have DT dependencies (like
clocks for phys in the above) because until you do, you don't need
child nodes.
> The gpio in question is called "mute", so I'd think the gpio-syscon driver
> should just define a "rockchip,rk3328-gpio-mute" compatible and contain
> all the register voodoo in the driver itself and not define it in the dt.
Is there really just one GPIO? If it has a defined function, then is
it really GP? Can you control direction? I know Linus W doesn't like
that kind of abuse of GPIO.
> So it should probably look like
>
> grf: syscon at ff100000 {
> compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
>
> [all the other syscon sub-devices]
>
> gpio_mute: gpio-mute {
> compatible = "rockchip,rk3328-gpio-mute";
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> [more other syscon sub-devices]
> };
^ permalink raw reply
* [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Rob Herring @ 2018-05-23 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1709653.qERUERh18a@avalon>
On Wed, May 23, 2018 at 2:38 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Rob,
>
> On Wednesday, 23 May 2018 19:29:47 EEST Rob Herring wrote:
>> On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
>> > Describe the optional endpoint properties for endpoint nodes of port at 0
>> > and port at 1 of the R-Car VIN driver device tree bindings documentation.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> > ---
>> >
>> > Documentation/devicetree/bindings/media/rcar_vin.txt | 13 ++++++++++++-
>> > 1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > b/Documentation/devicetree/bindings/media/rcar_vin.txt index
>> > a19517e1..c53ce4e 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on
>> > SoC.
>> >
>> > from external SoC pins described in video-interfaces.txt[1].
>> > Describing more then one endpoint in port 0 is invalid. Only VIN
>> > instances that are connected to external pins should have port 0.
>> >
>> > +
>> > + - Optional properties for endpoint nodes of port at 0:
>> > + - hsync-active: active state of the HSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > + - vsync-active: active state of the VSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > +
>> > + If both HSYNC and VSYNC polarities are not specified, embedded
>> > + synchronization is selected.
>>
>> No need to copy-n-paste from video-interfaces.txt. Just "see
>> video-interfaces.txt" for the description is fine.
>
> I would still explicitly list the properties that apply to this binding. I
> agree that there's no need to copy & paste the description of those properties
> though.
Yes, that's what I meant. List each property with "see
video-interfaces.txt" for the description of each.
Rob
^ permalink raw reply
* [PATCH 1/2] ti: wkup_m3_ipc: Add rtc_only with ddr in self refresh mode support
From: Keerthy @ 2018-05-23 20:03 UTC (permalink / raw)
To: linux-arm-kernel
Adds rtc_only support. This needs resume function to shutdown and
reboot the m3.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
This is tested on am437x-gp-evm and target for 4.19
drivers/soc/ti/wkup_m3_ipc.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/linux/wkup_m3_ipc.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index 369aef5..b732c39 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -329,12 +329,24 @@ static int wkup_m3_finish_low_power(struct wkup_m3_ipc *m3_ipc)
return 0;
}
+/**
+ * wkup_m3_set_rtc_only - Set the rtc_only flag
+ * @wkup_m3_wakeup: struct wkup_m3_wakeup_src * gets assigned the
+ * wakeup src value
+ */
+static void wkup_m3_set_rtc_only(struct wkup_m3_ipc *m3_ipc)
+{
+ if (m3_ipc_state)
+ m3_ipc_state->is_rtc_only = true;
+}
+
static struct wkup_m3_ipc_ops ipc_ops = {
.set_mem_type = wkup_m3_set_mem_type,
.set_resume_address = wkup_m3_set_resume_address,
.prepare_low_power = wkup_m3_prepare_low_power,
.finish_low_power = wkup_m3_finish_low_power,
.request_pm_status = wkup_m3_request_pm_status,
+ .set_rtc_only = wkup_m3_set_rtc_only,
};
/**
@@ -484,6 +496,32 @@ static int wkup_m3_ipc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int wkup_m3_ipc_suspend(struct device *dev)
+{
+ /*
+ * Nothing needs to be done on suspend even with rtc_only flag set
+ */
+ return 0;
+}
+
+static int wkup_m3_ipc_resume(struct device *dev)
+{
+ if (m3_ipc_state->is_rtc_only) {
+ rproc_shutdown(m3_ipc_state->rproc);
+ rproc_boot(m3_ipc_state->rproc);
+ }
+
+ m3_ipc_state->is_rtc_only = false;
+
+ return 0;
+}
+
+static const struct dev_pm_ops wkup_m3_ipc_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(wkup_m3_ipc_suspend, wkup_m3_ipc_resume)
+};
+#endif
+
static const struct of_device_id wkup_m3_ipc_of_match[] = {
{ .compatible = "ti,am3352-wkup-m3-ipc", },
{ .compatible = "ti,am4372-wkup-m3-ipc", },
@@ -497,6 +535,9 @@ static int wkup_m3_ipc_remove(struct platform_device *pdev)
.driver = {
.name = "wkup_m3_ipc",
.of_match_table = wkup_m3_ipc_of_match,
+#ifdef CONFIG_PM
+ .pm = &wkup_m3_ipc_pm_ops,
+#endif
},
};
diff --git a/include/linux/wkup_m3_ipc.h b/include/linux/wkup_m3_ipc.h
index d6ba7d3..d639df1 100644
--- a/include/linux/wkup_m3_ipc.h
+++ b/include/linux/wkup_m3_ipc.h
@@ -40,6 +40,7 @@ struct wkup_m3_ipc {
struct mbox_chan *mbox;
struct wkup_m3_ipc_ops *ops;
+ int is_rtc_only;
};
struct wkup_m3_ipc_ops {
@@ -48,8 +49,10 @@ struct wkup_m3_ipc_ops {
int (*prepare_low_power)(struct wkup_m3_ipc *m3_ipc, int state);
int (*finish_low_power)(struct wkup_m3_ipc *m3_ipc);
int (*request_pm_status)(struct wkup_m3_ipc *m3_ipc);
+ void (*set_rtc_only)(struct wkup_m3_ipc *m3_ipc);
};
struct wkup_m3_ipc *wkup_m3_ipc_get(void);
void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc);
+void wkup_m3_set_rtc_only_mode(void);
#endif /* _LINUX_WKUP_M3_IPC_H */
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] soc: ti: wkup_m3_ipc: Add wkup_m3_request_wake_src
From: Keerthy @ 2018-05-23 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527105786-23396-1-git-send-email-j-keerthy@ti.com>
From: Dave Gerlach <d-gerlach@ti.com>
Add wkup_m3_request_wake_src to allow users to get the name of
the wakeup source after a DeepSleep or Standby transition.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
This is tested on am437x-gp-evm and target for 4.19
drivers/soc/ti/wkup_m3_ipc.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/wkup_m3_ipc.h | 6 ++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index b732c39..6840688 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -46,6 +46,7 @@
#define M3_BASELINE_VERSION 0x191
#define M3_STATUS_RESP_MASK (0xffff << 16)
#define M3_FW_VERSION_MASK 0xffff
+#define M3_WAKE_SRC_MASK 0xff
#define M3_STATE_UNKNOWN 0
#define M3_STATE_RESET 1
@@ -55,6 +56,23 @@
static struct wkup_m3_ipc *m3_ipc_state;
+static const struct wkup_m3_wakeup_src wakeups[] = {
+ {.irq_nr = 35, .src = "USB0_PHY"},
+ {.irq_nr = 36, .src = "USB1_PHY"},
+ {.irq_nr = 40, .src = "I2C0"},
+ {.irq_nr = 41, .src = "RTC Timer"},
+ {.irq_nr = 42, .src = "RTC Alarm"},
+ {.irq_nr = 43, .src = "Timer0"},
+ {.irq_nr = 44, .src = "Timer1"},
+ {.irq_nr = 45, .src = "UART"},
+ {.irq_nr = 46, .src = "GPIO0"},
+ {.irq_nr = 48, .src = "MPU_WAKE"},
+ {.irq_nr = 49, .src = "WDT0"},
+ {.irq_nr = 50, .src = "WDT1"},
+ {.irq_nr = 51, .src = "ADC_TSC"},
+ {.irq_nr = 0, .src = "Unknown"},
+};
+
static void am33xx_txev_eoi(struct wkup_m3_ipc *m3_ipc)
{
writel(AM33XX_M3_TXEV_ACK,
@@ -330,6 +348,26 @@ static int wkup_m3_finish_low_power(struct wkup_m3_ipc *m3_ipc)
}
/**
+ * wkup_m3_request_wake_src - Get the wakeup source info passed from wkup_m3
+ * @m3_ipc: Pointer to wkup_m3_ipc context
+ */
+static const char *wkup_m3_request_wake_src(struct wkup_m3_ipc *m3_ipc)
+{
+ unsigned int wakeup_src_idx;
+ int j, val;
+
+ val = wkup_m3_ctrl_ipc_read(m3_ipc, 6);
+
+ wakeup_src_idx = val & M3_WAKE_SRC_MASK;
+
+ for (j = 0; j < ARRAY_SIZE(wakeups) - 1; j++) {
+ if (wakeups[j].irq_nr == wakeup_src_idx)
+ return wakeups[j].src;
+ }
+ return wakeups[j].src;
+}
+
+/**
* wkup_m3_set_rtc_only - Set the rtc_only flag
* @wkup_m3_wakeup: struct wkup_m3_wakeup_src * gets assigned the
* wakeup src value
@@ -346,6 +384,7 @@ static void wkup_m3_set_rtc_only(struct wkup_m3_ipc *m3_ipc)
.prepare_low_power = wkup_m3_prepare_low_power,
.finish_low_power = wkup_m3_finish_low_power,
.request_pm_status = wkup_m3_request_pm_status,
+ .request_wake_src = wkup_m3_request_wake_src,
.set_rtc_only = wkup_m3_set_rtc_only,
};
diff --git a/include/linux/wkup_m3_ipc.h b/include/linux/wkup_m3_ipc.h
index d639df1..e497e62 100644
--- a/include/linux/wkup_m3_ipc.h
+++ b/include/linux/wkup_m3_ipc.h
@@ -43,12 +43,18 @@ struct wkup_m3_ipc {
int is_rtc_only;
};
+struct wkup_m3_wakeup_src {
+ int irq_nr;
+ char src[10];
+};
+
struct wkup_m3_ipc_ops {
void (*set_mem_type)(struct wkup_m3_ipc *m3_ipc, int mem_type);
void (*set_resume_address)(struct wkup_m3_ipc *m3_ipc, void *addr);
int (*prepare_low_power)(struct wkup_m3_ipc *m3_ipc, int state);
int (*finish_low_power)(struct wkup_m3_ipc *m3_ipc);
int (*request_pm_status)(struct wkup_m3_ipc *m3_ipc);
+ const char *(*request_wake_src)(struct wkup_m3_ipc *m3_ipc);
void (*set_rtc_only)(struct wkup_m3_ipc *m3_ipc);
};
--
1.9.1
^ permalink raw reply related
* [PATCH V4 0/8] net: ethernet: stmmac: add support for stm32mp1
From: David Miller @ 2018-05-23 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527090479-5263-1-git-send-email-christophe.roullier@st.com>
From: Christophe Roullier <christophe.roullier@st.com>
Date: Wed, 23 May 2018 17:47:51 +0200
> Patches to have Ethernet support on stm32mp1
> Changelog:
> Remark from Rob Herring
> Move Documentation/devicetree/bindings/arm/stm32.txt in
> Documentation/devicetree/bindings/arm/stm32/stm32.txt and create
> Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
>
> Replace also in arch/arm/boot/dts/stm32mp157c.dtsi, syscfg: system-config at 50020000
> with syscfg: syscon at 50020000syscfg: system-config at 50020000
Probably the DTS file updates need to go in via the ARM tree, not
mine.
Can you respin a net-next targetted series that has just the driver
code and device tree binding updates?
Thank you!
^ permalink raw reply
* [PATCH v3 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain
From: Heiko Stübner @ 2018-05-23 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058286-10503-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:51:26 CEST schrieb Elaine Zhang:
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.18 (or later)
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 09/13] dt-bindings: add binding for rk3228 power domains
From: Heiko Stübner @ 2018-05-23 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058301-10553-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:51:41 CEST schrieb Elaine Zhang:
> Add binding documentation for the power domains
> found on Rockchip RK3228 SoCs.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
applied for 4.18 (or later)
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 10/13] soc: rockchip: power-domain: add power domain support for rk3228
From: Heiko Stübner @ 2018-05-23 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058323-10611-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:52:03 CEST schrieb Elaine Zhang:
> This driver is modified to support RK3228 SoC.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.18 (or later)
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Heiko Stübner @ 2018-05-23 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058341-10658-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:52:21 CEST schrieb Elaine Zhang:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.18 (or later)
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 12/13] dt-bindings: add binding for px30 power domains
From: Heiko Stübner @ 2018-05-23 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058371-10706-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:52:51 CEST schrieb Elaine Zhang:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> Add binding documentation for the power domains
> found on Rockchip PX30 SoCs.
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.18 (or later)
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 13/13] soc: rockchip: power-domain: add power domain support for px30
From: Heiko Stübner @ 2018-05-23 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527058412-10754-1-git-send-email-zhangqing@rock-chips.com>
Am Mittwoch, 23. Mai 2018, 08:53:32 CEST schrieb Elaine Zhang:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> This driver is modified to support PX30 SoC.
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.18 (or later)
Thanks
Heiko
^ 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