* [PATCH 2/7] regulator: core: Add regulator_set_voltage_rdev()
From: Maciej Purski @ 2018-06-04 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-1-git-send-email-m.purski@samsung.com>
Refactor regulator_set_voltage_unlocked() by taking code related to
regulator_dev and creating a new function regulator_set_voltage_rdev(),
which operates only on struct regulator_dev.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/regulator/core.c | 40 ++++++++++++++++++++++++++++------------
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b740426..413a824 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -105,6 +105,9 @@ static int _notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data);
static int _regulator_do_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV);
+static int regulator_set_voltage_rdev(struct regulator_dev *rdev,
+ int min_uV, int max_uV,
+ suspend_state_t state);
static struct regulator *create_regulator(struct regulator_dev *rdev,
struct device *dev,
const char *supply_name);
@@ -2996,8 +2999,6 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
int ret = 0;
int old_min_uV, old_max_uV;
int current_uV;
- int best_supply_uV = 0;
- int supply_change_uV = 0;
pr_err("%s: %d\n", __func__, __LINE__);
/* If we're setting the same range as last time the change
@@ -3042,6 +3043,26 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (ret < 0)
goto out2;
+ ret = regulator_set_voltage_rdev(rdev, min_uV, max_uV, state);
+ if (ret < 0)
+ goto out2;
+
+out:
+ return 0;
+out2:
+ voltage->min_uV = old_min_uV;
+ voltage->max_uV = old_max_uV;
+
+ return ret;
+}
+
+static int regulator_set_voltage_rdev(struct regulator_dev *rdev, int min_uV,
+ int max_uV, suspend_state_t state)
+{
+ int best_supply_uV = 0;
+ int supply_change_uV = 0;
+ int ret;
+
if (rdev->supply &&
regulator_ops_is_valid(rdev->supply->rdev,
REGULATOR_CHANGE_VOLTAGE) &&
@@ -3053,13 +3074,13 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
selector = regulator_map_voltage(rdev, min_uV, max_uV);
if (selector < 0) {
ret = selector;
- goto out2;
+ goto out;
}
best_supply_uV = _regulator_list_voltage(rdev, selector, 0);
if (best_supply_uV < 0) {
ret = best_supply_uV;
- goto out2;
+ goto out;
}
best_supply_uV += rdev->desc->min_dropout_uV;
@@ -3067,7 +3088,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
current_supply_uV = _regulator_get_voltage(rdev->supply->rdev);
if (current_supply_uV < 0) {
ret = current_supply_uV;
- goto out2;
+ goto out;
}
supply_change_uV = best_supply_uV - current_supply_uV;
@@ -3079,7 +3100,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (ret) {
dev_err(&rdev->dev, "Failed to increase supply voltage: %d\n",
ret);
- goto out2;
+ goto out;
}
}
@@ -3089,7 +3110,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
ret = _regulator_do_set_suspend_voltage(rdev, min_uV,
max_uV, state);
if (ret < 0)
- goto out2;
+ goto out;
if (supply_change_uV < 0) {
ret = regulator_set_voltage_unlocked(rdev->supply,
@@ -3103,11 +3124,6 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
out:
return ret;
-out2:
- voltage->min_uV = old_min_uV;
- voltage->max_uV = old_max_uV;
-
- return ret;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH 1/7] regulator: core: Add debug messages
From: Maciej Purski @ 2018-06-04 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-1-git-send-email-m.purski@samsung.com>
Add debug messages on voltage setting and enabling path in order
to debug the coupled regulators problem.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
---
drivers/regulator/core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6ed568b..b740426 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1571,6 +1571,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
struct device *dev = rdev->dev.parent;
int ret;
+ pr_err("%s: %d\n", __func__, __LINE__);
/* No supply to resovle? */
if (!rdev->supply_name)
return 0;
@@ -2211,6 +2212,7 @@ static int _regulator_enable(struct regulator_dev *rdev)
{
int ret;
+ pr_err("%s: %d\n", __func__, __LINE__);
lockdep_assert_held_once(&rdev->mutex);
/* check voltage and requested load before enabling */
@@ -2259,6 +2261,7 @@ int regulator_enable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+ pr_err("%s: %d\n", __func__, __LINE__);
if (regulator->always_on)
return 0;
@@ -2275,6 +2278,7 @@ int regulator_enable(struct regulator *regulator)
if (ret != 0 && rdev->supply)
regulator_disable(rdev->supply);
+ pr_err("%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_enable);
@@ -2373,6 +2377,7 @@ int regulator_disable(struct regulator *regulator)
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+ pr_err("%s: %d\n", __func__, __LINE__);
if (regulator->always_on)
return 0;
@@ -2383,6 +2388,7 @@ int regulator_disable(struct regulator *regulator)
if (ret == 0 && rdev->supply)
regulator_disable(rdev->supply);
+ pr_err("%s: %d\n", __func__, __LINE__);
return ret;
}
EXPORT_SYMBOL_GPL(regulator_disable);
@@ -2858,6 +2864,7 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
const struct regulator_ops *ops = rdev->desc->ops;
int old_uV = _regulator_get_voltage(rdev);
+ pr_err("%s: %d\n", __func__, __LINE__);
trace_regulator_set_voltage(rdev_get_name(rdev), min_uV, max_uV);
min_uV += rdev->constraints->uV_offset;
@@ -2992,6 +2999,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
int best_supply_uV = 0;
int supply_change_uV = 0;
+ pr_err("%s: %d\n", __func__, __LINE__);
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
@@ -3124,6 +3132,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
{
int ret = 0;
+ pr_err("%s: %d\n", __func__, __LINE__);
regulator_lock_supply(regulator->rdev);
ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV,
--
2.7.4
^ permalink raw reply related
* Regression in Linux next again
From: Maciej Purski @ 2018-06-04 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530144505.GB5705@atomide.com>
Hi,
this patchset contains previous two reverted patches. They were split
in order to make it easier to bisect, where the problem lies. It adds
also some simple debugs, which should help us track down the problem.
Tony, please apply this patchset and test it on your Beaglebone. It'd be
great if you could try to find out, which patch causes failure. They should
be appliable on the current next.
Thanks,
Maciej Purski
Maciej Purski (7):
regulator: core: Add debug messages
regulator: core: Add regulator_set_voltage_rdev()
regulator: core: Use re-entrant locks
regulator: core: Implement voltage balancing algorithm
regulator: core: Lock dependent regulators
regulator: core: Lock dependent regulators on regulator_enable()
regulator: core: Enable voltage balancing
drivers/regulator/core.c | 341 +++++++++++++++++++++++++++++++++++++++++------
1 file changed, 300 insertions(+), 41 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Faiz Abbas @ 2018-06-04 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601142613.GU5705@atomide.com>
Hi,
On Friday 01 June 2018 07:56 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180601 06:49]:
>> Hi,
>>
>> On Thursday 31 May 2018 06:59 PM, Tero Kristo wrote:
>>> On 31/05/18 13:14, Faiz Abbas wrote:
>>>> Hi,
>>>>
>>>> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
>>>>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>>>>>> Add clkctrl data for the m_can clocks and register it within the
>>>> ...
>>>>>> ? diff --git a/include/dt-bindings/clock/dra7.h
>>>>>> b/include/dt-bindings/clock/dra7.h
>>>>>> index 5e1061b15aed..d7549c57cac3 100644
>>>>>> --- a/include/dt-bindings/clock/dra7.h
>>>>>> +++ b/include/dt-bindings/clock/dra7.h
>>>>>> @@ -168,5 +168,6 @@
>>>>>> ? #define DRA7_COUNTER_32K_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x50)
>>>>>> ? #define DRA7_UART10_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x80)
>>>>>> ? #define DRA7_DCAN1_CLKCTRL??? DRA7_CLKCTRL_INDEX(0x88)
>>>>>> +#define DRA7_ADC_CLKCTRL??? DRA7_CLKCTRL_INDEX(0xa0)
>>>>>
>>>>> ADC and mcan are the same thing?
>>>>>
>>>>
>>>> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
>>>
>>> Is there any reason for this or is that just a documentation bug?
>>>
>>
>> Looks like they meant to have an ADC in dra74 or dra72 but decided
>> against it and then many years later used the same registers for MCAN
>> instead. You can see ADC_CLKCTRL exists in dra72 TRM but is explicitly
>> disabled.
>>
>> http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf pg:1524
>
> How about make add also something like to dra7.h:
>
> #define DRA7_MCAN_CLKCTRL DRA7_ADC_CLKCTRL
>
> And you can add a comment to the dts file to avoid people
> getting confused with this constantly.
>
I would prefer to follow the TRM so that people don't look for registers
that don't exist at all.
Thanks,
Faiz
^ permalink raw reply
* Applied "ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it" to the asoc tree
From: Mark Brown @ 2018-06-04 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604111326.15708-1-srinivas.kandagatla@linaro.org>
The patch
ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ff2faf1289c1f81b5b26b9451dd1c2006aac8db8 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date: Mon, 4 Jun 2018 12:13:26 +0100
Subject: [PATCH] ASoC: dapm: delete dapm_kcontrol_data paths list before
freeing it
dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
paths pointer dangling in the list.
This leads to system crash when we try to unload and reload sound card.
I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
Without this patch, on SLAB Poisoning enabled build, kernel crashes with
"BUG kmalloc-128 (Tainted: G W ): Poison overwritten"
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable at vger.kernel.org
---
sound/soc/soc-dapm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 1e9a36389667..36a39ba30226 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -433,6 +433,8 @@ static int dapm_kcontrol_data_alloc(struct snd_soc_dapm_widget *widget,
static void dapm_kcontrol_free(struct snd_kcontrol *kctl)
{
struct dapm_kcontrol_data *data = snd_kcontrol_chip(kctl);
+
+ list_del(&data->paths);
kfree(data->wlist);
kfree(data);
}
--
2.17.0
^ permalink raw reply related
* [PATCH v2] of: platform: stop accessing invalid dev in of_platform_device_destroy
From: Srinivas Kandagatla @ 2018-06-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ9AMDiYCfgGgHZ=XL_1yJjTdSA4Jb_GqHAZML3jwB6+Q@mail.gmail.com>
On 04/06/18 14:44, Rob Herring wrote:
> On Fri, Jun 1, 2018 at 7:03 PM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>> Immediately after the platform_device_unregister() the device will be cleaned up.
>> Accessing the freed pointer immediately after that will crash the system.
>>
>> Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
>> loading/unloading audio drivers in a loop on Qcom platforms.
>
> Curious, does the unittest not catch this too?
>
Not sure!
>>
>> Fix this by removing accessing the dev pointer.
>> Below is the carsh trace:
>
> s/carsh/crash/
Yep.
>
> [...]
>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index c00d81dfac0b..84c5c899187b 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -529,10 +529,13 @@ arch_initcall_sync(of_platform_default_populate_init);
>>
>> int of_platform_device_destroy(struct device *dev, void *data)
>> {
>> + struct device_node *np;
>> +
>> /* Do not touch devices not populated from the device tree */
>> if (!dev->of_node || !of_node_check_flag(dev->of_node, OF_POPULATED))
>> return 0;
>>
>> + np = dev->of_node;
>> /* Recurse for any nodes that were treated as busses */
>> if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
>> device_for_each_child(dev, NULL, of_platform_device_destroy);
>> @@ -544,8 +547,8 @@ int of_platform_device_destroy(struct device *dev, void *data)
>> amba_device_unregister(to_amba_device(dev));
>> #endif
>>
>> - of_node_clear_flag(dev->of_node, OF_POPULATED);
>> - of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
>
> Just move these 2 lines to before unregister calls.
Make sense.. I will do that in v3.
thanks,
srini
>
>> + of_node_clear_flag(np, OF_POPULATED);
>> + of_node_clear_flag(np, OF_POPULATED_BUS);
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(of_platform_device_destroy);
>> --
>> 2.16.2
>>
^ permalink raw reply
* [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Richard Cochran @ 2018-06-04 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604070837.19265-10-yangbo.lu@nxp.com>
On Mon, Jun 04, 2018 at 03:08:36PM +0800, Yangbo Lu wrote:
> +if FSL_DPAA_ETH
> +config FSL_DPAA_ETH_TS
> + bool "DPAA hardware timestamping support"
> + select PTP_1588_CLOCK_QORIQ
> + default n
> + help
> + Enable DPAA hardware timestamping support.
> + This option is useful for applications to get
> + hardware time stamps on the Ethernet packets
> + using the SO_TIMESTAMPING API.
> +endif
You should drop this #ifdef. In general, if a MAC supports time
stamping and PHC, then the driver support should simply be compiled
in.
[ When time stamping incurs a large run time performance penalty to
non-PTP users, then it might make sense to have a Kconfig option to
disable it, but that doesn't appear to be the case here. ]
> @@ -1615,6 +1635,24 @@ static int dpaa_eth_refill_bpools(struct dpaa_priv *priv)
> skbh = (struct sk_buff **)phys_to_virt(addr);
> skb = *skbh;
>
> +#ifdef CONFIG_FSL_DPAA_ETH_TS
> + if (priv->tx_tstamp &&
> + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
This condition fits on one line easily.
> + struct skb_shared_hwtstamps shhwtstamps;
> + u64 ns;
Local variables belong at the top of the function.
> + memset(&shhwtstamps, 0, sizeof(shhwtstamps));
> +
> + if (!dpaa_get_tstamp_ns(priv->net_dev, &ns,
> + priv->mac_dev->port[TX],
> + (void *)skbh)) {
> + shhwtstamps.hwtstamp = ns_to_ktime(ns);
> + skb_tstamp_tx(skb, &shhwtstamps);
> + } else {
> + dev_warn(dev, "dpaa_get_tstamp_ns failed!\n");
> + }
> + }
> +#endif
> if (unlikely(qm_fd_get_format(fd) == qm_fd_sg)) {
> nr_frags = skb_shinfo(skb)->nr_frags;
> dma_unmap_single(dev, addr, qm_fd_get_offset(fd) +
> @@ -2086,6 +2124,14 @@ static int dpaa_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
> if (unlikely(err < 0))
> goto skb_to_fd_failed;
>
> +#ifdef CONFIG_FSL_DPAA_ETH_TS
> + if (priv->tx_tstamp &&
> + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
One line please.
> + fd.cmd |= FM_FD_CMD_UPD;
> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> + }
> +#endif
> +
> if (likely(dpaa_xmit(priv, percpu_stats, queue_mapping, &fd) == 0))
> return NETDEV_TX_OK;
>
Thanks,
Richard
^ permalink raw reply
* [PATCH v2] of: platform: stop accessing invalid dev in of_platform_device_destroy
From: Rob Herring @ 2018-06-04 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602000343.20045-1-srinivas.kandagatla@linaro.org>
On Fri, Jun 1, 2018 at 7:03 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> Immediately after the platform_device_unregister() the device will be cleaned up.
> Accessing the freed pointer immediately after that will crash the system.
>
> Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
> loading/unloading audio drivers in a loop on Qcom platforms.
Curious, does the unittest not catch this too?
>
> Fix this by removing accessing the dev pointer.
> Below is the carsh trace:
s/carsh/crash/
[...]
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index c00d81dfac0b..84c5c899187b 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -529,10 +529,13 @@ arch_initcall_sync(of_platform_default_populate_init);
>
> int of_platform_device_destroy(struct device *dev, void *data)
> {
> + struct device_node *np;
> +
> /* Do not touch devices not populated from the device tree */
> if (!dev->of_node || !of_node_check_flag(dev->of_node, OF_POPULATED))
> return 0;
>
> + np = dev->of_node;
> /* Recurse for any nodes that were treated as busses */
> if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
> device_for_each_child(dev, NULL, of_platform_device_destroy);
> @@ -544,8 +547,8 @@ int of_platform_device_destroy(struct device *dev, void *data)
> amba_device_unregister(to_amba_device(dev));
> #endif
>
> - of_node_clear_flag(dev->of_node, OF_POPULATED);
> - of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
Just move these 2 lines to before unregister calls.
> + of_node_clear_flag(np, OF_POPULATED);
> + of_node_clear_flag(np, OF_POPULATED_BUS);
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_platform_device_destroy);
> --
> 2.16.2
>
^ permalink raw reply
* [PATCH v12 3/5] arm64: pgtable: Add p*d_page_vaddr helper macros
From: Chintan Pandya @ 2018-06-04 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604121351.GJ9482@arm.com>
On 6/4/2018 5:43 PM, Will Deacon wrote:
> On Fri, Jun 01, 2018 at 06:09:16PM +0530, Chintan Pandya wrote:
>> Add helper macros to give virtual references to page
>> tables. These will be used while freeing dangling
>> page tables.
>>
>> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
>> ---
>> arch/arm64/include/asm/pgtable.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 7c4c8f3..ef4047f 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -580,6 +580,9 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
>>
>> #endif /* CONFIG_PGTABLE_LEVELS > 3 */
>>
>> +#define pmd_page_vaddr(pmd) __va(pmd_page_paddr(pmd))
>> +#define pud_page_vaddr(pud) __va(pud_page_paddr(pud))
>
> Are these actually needed, or do pte_offset_kernel and pmd_offset do the
> job already?
>
I introduced these macros for consistency across different arch.
Looking at pte_offset_kernel, it seems to use READ_ONCE() which looks
little costly for its intended use (in next patch) where we already have
dereferenced value. Do you still suggest to remove this ?
> Will
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH v12 4/5] arm64: Implement page table free interfaces
From: Chintan Pandya @ 2018-06-04 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604121328.GG9482@arm.com>
On 6/4/2018 5:43 PM, Will Deacon wrote:
> On Fri, Jun 01, 2018 at 06:09:17PM +0530, Chintan Pandya wrote:
>> Implement pud_free_pmd_page() and pmd_free_pte_page().
>>
>> Implementation requires,
>> 1) Clearing off the current pud/pmd entry
>> 2) Invalidate TLB which could have previously
>> valid but not stale entry
>> 3) Freeing of the un-used next level page tables
>
> Please can you rewrite this describing the problem that you're solving,
> rather than a brief summary of some requirements?
Okay. I'll fix this in v13.
>
>> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
>> ---
>> arch/arm64/mm/mmu.c | 38 ++++++++++++++++++++++++++++++++++----
>> 1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 8ae5d7a..6e7e16c 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -45,6 +45,7 @@
>> #include <asm/memblock.h>
>> #include <asm/mmu_context.h>
>> #include <asm/ptdump.h>
>> +#include <asm/tlbflush.h>
>>
>> #define NO_BLOCK_MAPPINGS BIT(0)
>> #define NO_CONT_MAPPINGS BIT(1)
>> @@ -977,12 +978,41 @@ int pmd_clear_huge(pmd_t *pmdp)
>> return 1;
>> }
>>
>> -int pud_free_pmd_page(pud_t *pud, unsigned long addr)
>> +int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
>> {
>> - return pud_none(*pud);
>> + pte_t *table;
>> + pmd_t pmd;
>> +
>> + pmd = READ_ONCE(*pmdp);
>> + if (pmd_present(pmd)) {
>> + table = pmd_page_vaddr(pmd);
>> + pmd_clear(pmdp);
>> + __flush_tlb_kernel_pgtable(addr);
>> + pte_free_kernel(NULL, table);
>> + }
>> + return 1;
>> }
>>
>> -int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
>> +int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
>> {
>> - return pmd_none(*pmd);
>> + pmd_t *table;
>> + pmd_t *entry;
>> + pud_t pud;
>> + unsigned long next, end;
>> +
>> + pud = READ_ONCE(*pudp);
>> + if (pud_present(pud)) {
>
> Just some stylistic stuff, but please can you rewrite this as:
>
> if (!pud_present(pud) || VM_WARN_ON(!pud_table(pud)))
> return 1;
>
> similarly for the pmd/pte code above.
Okay. v13 will have this.
>
>> + table = pud_page_vaddr(pud);
>> + entry = table;
>
> Could you rename entry -> pmdp, please?
Sure.
>
>> + next = addr;
>> + end = addr + PUD_SIZE;
>> + do {
>> + pmd_free_pte_page(entry, next);
>> + } while (entry++, next += PMD_SIZE, next != end);
>> +
>> + pud_clear(pudp);
>> + __flush_tlb_kernel_pgtable(addr);
>> + pmd_free(NULL, table);
>> + }
>> + return 1;
>
> So with these patches, we only ever return 1 from these helpers. It looks
> like the same is true for x86, so how about we make them void and move the
> calls inside the conditionals in lib/ioremap.c? Obviously, this would be a
> separate patch on the end.
That sounds valid code churn to me. But since x86 discussion is not
concluded yet, I would wait to share until that gets resolved. May be
not in v13 but separate effort. Would that be okay to you ?
>
> Will
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH v12 5/5] arm64: Allow huge io mappings again
From: Chintan Pandya @ 2018-06-04 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604121452.GK9482@arm.com>
On 6/4/2018 5:44 PM, Will Deacon wrote:
> On Fri, Jun 01, 2018 at 06:09:18PM +0530, Chintan Pandya wrote:
>> Huge mappings have had stability issues due to stale
>> TLB entry and memory leak issues. Since, those are
>> addressed in this series of patches, it is now safe
>> to allow huge mappings.
>>
>> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
>> ---
>> arch/arm64/mm/mmu.c | 18 ++----------------
>> 1 file changed, 2 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 6e7e16c..c65abc4 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -934,15 +934,8 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
>> {
>> pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
>> pgprot_val(mk_sect_prot(prot)));
>> - pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot);
>> -
>> - /* Only allow permission changes for now */
>> - if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)),
>> - pud_val(new_pud)))
>> - return 0;
>
> Do you actually need to remove these checks? If we're doing
> break-before-make properly, then the check won't fire but it would be
> good to keep it there so we can catch misuse of these in future.
>
> In other words, can we drop this patch?
Yes, we don't need this patch as BBM is happening before this. I missed
that. I'll remove this patch in v13.
>
> Will
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH] media: atmel-isi: move of_node_put() to cover success branch as well
From: Ludovic Desroches @ 2018-06-04 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527859814-30410-1-git-send-email-hofrat@opentech.at>
On Fri, Jun 01, 2018 at 01:30:14PM +0000, Nicholas Mc Guire wrote:
> From: Nicholas Mc Guire <hofrat@osadl.org>
>
> The of_node_put() was only covering the error branch but missed the
> success branch so the refcount for ep which
> of_graph_get_remote_port_parent() incremented on success would was
> not being decremented.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Thanks
> ---
>
> This patch is on top of: "media: atmel-isi: drop unnecessary while loop"
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, CONFIG_MEDIA_CONTROLLER=y, V4L_PLATFORM_DRIVERS=y
> OF=y, CONFIG_COMPILE_TEST=y, CONFIG_VIDEO_ATMEL_ISI=y
>
> Compile testing atmel-isi.c shows some sparse warnings. Seems to be due to
> sizeof operator being applied to a union (not related to the function being
> changed though).
>
> Patch is against 4.17-rc7 (localversion-next is next-20180531)
>
> drivers/media/platform/atmel/atmel-isi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
> index 85fc7b9..e8db4df 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1111,10 +1111,9 @@ static int isi_graph_parse(struct atmel_isi *isi, struct device_node *node)
> return -EINVAL;
>
> remote = of_graph_get_remote_port_parent(ep);
> - if (!remote) {
> - of_node_put(ep);
> + of_node_put(ep);
> + if (!remote)
> return -EINVAL;
> - }
>
> /* Remote node to connect */
> isi->entity.node = remote;
> --
> 2.1.4
>
^ permalink raw reply
* [Resend PATCH 1/1] mtd: ubi: Update ubi-media.h to dual license
From: Richard Weinberger @ 2018-06-04 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604132137.32136-2-lionel.debieve@st.com>
Am Montag, 4. Juni 2018, 15:21:37 CEST schrieb Lionel Debieve:
> Update license template using SPDX. Move the global layout
> of UBI headers to dual license helping UBI to be the standard
> solution for raw NAND management.
>
> Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> drivers/mtd/ubi/ubi-media.h | 22 +++-------------------
> 1 file changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/ubi/ubi-media.h b/drivers/mtd/ubi/ubi-media.h
> index bfceae5a890e..195ff8ca8211 100644
> --- a/drivers/mtd/ubi/ubi-media.h
> +++ b/drivers/mtd/ubi/ubi-media.h
> @@ -1,28 +1,12 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> /*
> - * Copyright (c) International Business Machines Corp., 2006
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> - *
> + * Copyright (C) International Business Machines Corp., 2006
> * Authors: Artem Bityutskiy (???????????????? ??????????)
> * Thomas Gleixner
> * Frank Haverkamp
> * Oliver Lohmann
> * Andreas Arnez
> - */
> -
> -/*
> + *
> * This file defines the layout of UBI headers and all the other UBI on-flash
> * data structures.
> */
>
Applied.
Thanks everyone for sorting this out!
Thanks,
//richard
^ permalink raw reply
* [PATCH] media: atmel-isi: drop unnecessary while loop
From: Ludovic Desroches @ 2018-06-04 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527857174-24616-1-git-send-email-hofrat@opentech.at>
On Fri, Jun 01, 2018 at 12:46:14PM +0000, Nicholas Mc Guire wrote:
> From: Nicholas Mc Guire <hofrat@osadl.org>
>
> As there is no way this can loop it actually makes no sense to have
> a while(1){} around the body - all three possible paths end in a return
> statement.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Fixes: commit c1d82b895380 "[media] atmel-isi: move out of soc_camera to atmel"
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Thanks.
> ---
>
> The diff output is unfortunately not that readable - essentially only
> the outer while(1){ } was removed.
>
> Patch was compile tested with: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, CONFIG_MEDIA_CONTROLLER=y, V4L_PLATFORM_DRIVERS=y
> OF=y, CONFIG_COMPILE_TEST=y, CONFIG_VIDEO_ATMEL_ISI=y
>
> Compile testing atmel-isi.c shows some sparse warnings. Seems to be due to
> sizeof operator being applied to a union (not related to the function being
> changed though).
>
> Patch is against 4.17-rc7 (localversion-next is next-20180531)
>
> drivers/media/platform/atmel/atmel-isi.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
> index e5be21a..85fc7b9 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1106,23 +1106,21 @@ static int isi_graph_parse(struct atmel_isi *isi, struct device_node *node)
> struct device_node *ep = NULL;
> struct device_node *remote;
>
> - while (1) {
> - ep = of_graph_get_next_endpoint(node, ep);
> - if (!ep)
> - return -EINVAL;
> -
> - remote = of_graph_get_remote_port_parent(ep);
> - if (!remote) {
> - of_node_put(ep);
> - return -EINVAL;
> - }
> + ep = of_graph_get_next_endpoint(node, ep);
> + if (!ep)
> + return -EINVAL;
>
> - /* Remote node to connect */
> - isi->entity.node = remote;
> - isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> - return 0;
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote) {
> + of_node_put(ep);
> + return -EINVAL;
> }
> +
> + /* Remote node to connect */
> + isi->entity.node = remote;
> + isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> + isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> + return 0;
> }
>
> static int isi_graph_init(struct atmel_isi *isi)
> --
> 2.1.4
>
^ permalink raw reply
* [Resend PATCH 1/1] mtd: ubi: Update ubi-media.h to dual license
From: Lionel Debieve @ 2018-06-04 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604132137.32136-1-lionel.debieve@st.com>
Update license template using SPDX. Move the global layout
of UBI headers to dual license helping UBI to be the standard
solution for raw NAND management.
Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
drivers/mtd/ubi/ubi-media.h | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/ubi/ubi-media.h b/drivers/mtd/ubi/ubi-media.h
index bfceae5a890e..195ff8ca8211 100644
--- a/drivers/mtd/ubi/ubi-media.h
+++ b/drivers/mtd/ubi/ubi-media.h
@@ -1,28 +1,12 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
/*
- * Copyright (c) International Business Machines Corp., 2006
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
+ * Copyright (C) International Business Machines Corp., 2006
* Authors: Artem Bityutskiy (???????????????? ??????????)
* Thomas Gleixner
* Frank Haverkamp
* Oliver Lohmann
* Andreas Arnez
- */
-
-/*
+ *
* This file defines the layout of UBI headers and all the other UBI on-flash
* data structures.
*/
--
2.15.1
^ permalink raw reply related
* [Resend PATCH 0/1] mtd: ubi: Update ubi-media.h to dual license
From: Lionel Debieve @ 2018-06-04 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Resend the patch about license change, with ack from IBM.
Following previous mail about the dual license update for ubi-media.h file
(ie http://lists.infradead.org/pipermail/linux-mtd/2018-January/078878.html),
this is the corresponding patch about the requested change.
Lionel Debieve (1):
mtd: ubi: Update ubi-media.h to dual license
Update license template using SPDX. Move the global layout of UBI
headers to dual license helping UBI to be the standard solution for
raw NAND management.
drivers/mtd/ubi/ubi-media.h | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v4.9-stable] serial: pl011: add console matching function
From: Ard Biesheuvel @ 2018-06-04 13:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Aleksey Makarov <aleksey.makarov@linaro.org>
Commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream.
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
This patch was merged to tty-next but then reverted because of
conflict with
commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses")
Now it is fixed.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Please consider for v4.9-stable. It is the missing puzzle piece for SPCR
support on arm64 ACPI systems, which got merged for v4.9 [0]. Now that more
systems are becoming available to people working in the kernel community, it
turns out that v4.9 distro installers (e.g., Debian Stretch) won't work
unless you pass a 'console=' parameter explicitly, which is annoying.
Given that it was clearly the intent to include this code at the time,
I hope it will be considered for backporting.
[0] To quote the tty maintainer:
Also in here is the long-suffering ACPI SPCR patchset, which was
passed around from maintainer to maintainer like a hot-potato. Seems I
was the sucker^Wlucky one. All of those patches have been acked by the
various subsystem maintainers as well.
drivers/tty/serial/amba-pl011.c | 55 ++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index b42d7f1c9089..6b1863293fe1 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2320,12 +2320,67 @@ static int __init pl011_console_setup(struct console *co, char *options)
return uart_set_options(&uap->port, co, baud, parity, bits, flow);
}
+/**
+ * pl011_console_match - non-standard console matching
+ * @co: registering console
+ * @name: name from console command line
+ * @idx: index from console command line
+ * @options: ptr to option string from console command line
+ *
+ * Only attempts to match console command lines of the form:
+ * console=pl011,mmio|mmio32,<addr>[,<options>]
+ * console=pl011,0x<addr>[,<options>]
+ * This form is used to register an initial earlycon boot console and
+ * replace it with the amba_console at pl011 driver init.
+ *
+ * Performs console setup for a match (as required by interface)
+ * If no <options> are specified, then assume the h/w is already setup.
+ *
+ * Returns 0 if console matches; otherwise non-zero to use default matching
+ */
+static int __init pl011_console_match(struct console *co, char *name, int idx,
+ char *options)
+{
+ unsigned char iotype;
+ resource_size_t addr;
+ int i;
+
+ if (strcmp(name, "pl011") != 0)
+ return -ENODEV;
+
+ if (uart_parse_earlycon(options, &iotype, &addr, &options))
+ return -ENODEV;
+
+ if (iotype != UPIO_MEM && iotype != UPIO_MEM32)
+ return -ENODEV;
+
+ /* try to match the port specified on the command line */
+ for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
+ struct uart_port *port;
+
+ if (!amba_ports[i])
+ continue;
+
+ port = &amba_ports[i]->port;
+
+ if (port->mapbase != addr)
+ continue;
+
+ co->index = i;
+ port->cons = co;
+ return pl011_console_setup(co, options);
+ }
+
+ return -ENODEV;
+}
+
static struct uart_driver amba_reg;
static struct console amba_console = {
.name = "ttyAMA",
.write = pl011_console_write,
.device = uart_console_device,
.setup = pl011_console_setup,
+ .match = pl011_console_match,
.flags = CON_PRINTBUFFER,
.index = -1,
.data = &amba_reg,
--
2.17.0
^ permalink raw reply related
* [PATCH v6 6/9] dt-bindings: counter: Document stm32 quadrature encoder
From: Benjamin Gaignard @ 2018-06-04 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518162815.GA24966@rob-hp-laptop>
2018-05-18 18:28 GMT+02:00 Rob Herring <robh@kernel.org>:
> On Thu, May 17, 2018 at 08:59:40PM +0200, Benjamin Gaignard wrote:
>> 2018-05-17 18:23 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
>> > On Wed, May 16, 2018 at 12:51 PM, William Breathitt Gray
>> > <vilhelm.gray@gmail.com> wrote:
>> >> From: Benjamin Gaignard <benjamin.gaignard@st.com>
>> >
>> > v6? Where's v1-v5?
>> >
>> >> Add bindings for STM32 Timer quadrature encoder.
>> >> It is a sub-node of STM32 Timer which implement the
>> >> counter part of the hardware.
>> >>
>> >> Cc: Rob Herring <robh+dt@kernel.org>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> >> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>> >> ---
>> >> .../bindings/counter/stm32-timer-cnt.txt | 26 +++++++++++++++++++
>> >> .../devicetree/bindings/mfd/stm32-timers.txt | 7 +++++
>> >> 2 files changed, 33 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> >> new file mode 100644
>> >> index 000000000000..377728128bef
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
>> >> @@ -0,0 +1,26 @@
>> >> +STMicroelectronics STM32 Timer quadrature encoder
>> >> +
>> >> +STM32 Timer provides quadrature encoder counter mode to detect
>> >
>> > 'mode' does not sound like a sub-block of the timers block.
>>
>> quadrature encoding is one of the counting modes of this hardware
>> block which is enable to count on other signals/triggers
>
> You don't need a child node and compatible to set a mode.
"mode" isn't the good word here because quadratic encoder enable a
sub-block of this hardware.
Timer internal counter input could be internal or external clocks,
some IIO triggers
or the output of the quadratic encoder sub-block.
It is a child like pwm or IIO trigger.
>
>> >> +angular position and direction of rotary elements,
>> >> +from IN1 and IN2 input signals.
>> >> +
>> >> +Must be a sub-node of an STM32 Timer device tree node.
>> >> +See ../mfd/stm32-timers.txt for details about the parent node.
>> >> +
>> >> +Required properties:
>> >> +- compatible: Must be "st,stm32-timer-counter".
>> >> +- pinctrl-names: Set to "default".
>> >> +- pinctrl-0: List of phandles pointing to pin configuration nodes,
>> >> + to set IN1/IN2 pins in mode of operation for Low-Power
>> >> + Timer input on external pin.
>> >> +
>> >> +Example:
>> >> + timers at 40010000 {
>> >> + compatible = "st,stm32-timers";
>> >> + ...
>> >> + counter {
>> >> + compatible = "st,stm32-timer-counter";
>> >
>> > Is there only 1? How is the counter addressed?
>>
>> Yes there is only one counter per hardware block.
>> Counter is addressed like the two others sub-nodes and the details
>> about parent mode are describe in stm32-timers.txt
>> Should I add them here too ? so example will be like that:
>
> No, you should drop the child node and add pinctrl to the parent.
>
> Any other functions this block has that you plan on adding? Please make
> bindings as complete as possible, not what you currently have drivers
> for.
Counter framework didn't exist when I pushed timer node but thanks to
William's effort
it will allow us to use this kindf of hardware
Benjamin
>
>> timers at 40010000 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "st,stm32-timers";
>> reg = <0x40010000 0x400>;
>> clocks = <&rcc 0 160>;
>> clock-names = "int";
>> counter {
>> compatible = "st,stm32-timer-counter";
>> pinctrl-names = "default";
>> pinctrl-0 = <&tim1_in_pins>;
>> };
>> };
>>
>> Benjamin
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Josh Boyer @ 2018-06-04 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bcb4ba3ccd3b139ce03b6736d8d07cbe@codeaurora.org>
On Sat, May 26, 2018 at 4:18 AM Vikash Garodia <vgarodia@codeaurora.org> wrote:
>
> Hi Josh,
>
> On 2018-05-25 17:34, Josh Boyer wrote:
> > On Fri, May 25, 2018 at 7:03 AM Vikash Garodia
> > <vgarodia@codeaurora.org>
> > wrote:
> >
> >> This pull request adds firmware files for Venus h/w codec found on the
> > Qualcomm SDM845 chipset.
> >
> >> The following changes since commit
> > 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> >
> >> Merge branch 'for-upstreaming-v1.7.2' of
> > https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22
> > -0400)
> >
> >> are available in the git repository at:
> >
> >
> >> https://github.com/vgarodia/linux-firmware master
> >
> >> for you to fetch changes up to
> >> d6088b9c9d7f49d3c6c43681190889eca0abdcce:
> >
> >> qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
> >
> >> ----------------------------------------------------------------
> >> Vikash Garodia (1):
> >> qcom: add venus firmware files for v5.2
> >
> >> WHENCE | 9 +++++++++
> >> qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
> >> qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
> >> qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
> >> qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
> >> qcom/venus-5.2/venus.b04 | 1 +
> >> qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
> >> qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
> >> 8 files changed, 10 insertions(+)
> >> create mode 100644 qcom/venus-5.2/venus.b00
> >> create mode 100644 qcom/venus-5.2/venus.b01
> >> create mode 100644 qcom/venus-5.2/venus.b02
> >> create mode 100644 qcom/venus-5.2/venus.b03
> >> create mode 100644 qcom/venus-5.2/venus.b04
> >> create mode 100644 qcom/venus-5.2/venus.mbn
> >> create mode 100644 qcom/venus-5.2/venus.mdt
> >
> > The venus.mbn file isn't mentioned in WHENCE:
> >
> > [jwboyer at vader linux-firmware]$ ./check_whence.py
> > E: qcom/venus-5.2/venus.mbn not listed in WHENCE
> > [jwboyer at vader linux-firmware]$
> >
> > Can you fix that up and let me know when to re-pull?
> I have fixed the error and is ready to be re-pulled from the same git
> repository.
> I have noted the process to run check_whence.py before uploading the
> firmwares.
>
> Do i need to resend the pull request as the end commit is now changed to
> 7602644358157e4b89960472b6d59ffcc040ca52 ?
Nope. Pulled and pushed out now. Thanks.
josh
^ permalink raw reply
* [PATCH 0/6] ARM: shmobile: rcar: Drop lehacy SYSC fallbacks
From: Simon Horman @ 2018-06-04 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604101307.gwakbdqnka6arhxc@verge.net.au>
On Mon, Jun 04, 2018 at 12:13:08PM +0200, Simon Horman wrote:
> On Wed, May 30, 2018 at 05:25:10PM +0200, Geert Uytterhoeven wrote:
> > Hi Simon, Magnus,
> >
> > When DT SYSC support was introduced in v4.7, legacy fallbacks were kept
> > to keep secondary CPUs working on R-Car H1, H2, and M2-W using old DTBs.
> > However, the time has come to drop these fallbacks, and clean up the
> > resulting code.
> >
> > Most of this was written when I worked on DT SYSC support, but postponed
> > until the time was ripe. So basically I've been running this during the
> > last +2 years.
> >
> > I avoided touching drivers/soc/renesas and arch/arm/mach-shmobile code
> > in the same patch. If you prefer some patches to be squashed, please
> > let me know.
> >
> > Tested on Marzen (R-Car H1), Lager (R-Car H2), and Koelsch (R-Car M2-W).
> >
> > Thanks!
> >
> > Geert Uytterhoeven (6):
> > ARM: shmobile: rcar-gen2: Remove explicit SYSC config and init
> > ARM: shmobile: r8a7779: Stop powering down secondary CPUs during early
> > boot
> > soc: renesas: rcar-sysc: Provide helpers to power up/down CPUs
> > ARM: shmobile: r8a7779: Use rcar_sysc_power_{down,up}_cpu()
> > ARM: shmobile: r8a7779: Remove explicit SYSC config and init
> > soc: renesas: rcar-sysc: Drop legacy handling
> >
> > arch/arm/mach-shmobile/Makefile | 2 +-
> > arch/arm/mach-shmobile/pm-r8a7779.c | 41 ----------------------
> > arch/arm/mach-shmobile/pm-rcar-gen2.c | 25 --------------
> > arch/arm/mach-shmobile/r8a7779.h | 2 --
> > arch/arm/mach-shmobile/smp-r8a7779.c | 54 ++++-------------------------
> > drivers/soc/renesas/rcar-sysc.c | 64 ++++++++++++++++++++++-------------
> > include/linux/soc/renesas/rcar-sysc.h | 13 ++-----
> > 7 files changed, 50 insertions(+), 151 deletions(-)
> > delete mode 100644 arch/arm/mach-shmobile/pm-r8a7779.c
>
> Thanks, I have applied this and intend to push shortly.
>
> I had a conflict in the Makefile when applying patch 5/6.
> Please check to make sure I applied that patch correctly.
Sorry for the noise. I found that the conflict was caused by
an error on my part. I fixed that and the series applied cleanly.
The result is in renesas-devel-20180604-v4.17-rc7.
^ permalink raw reply
* [PATCH] rtc: sunxi: fix possible race condition
From: Maxime Ripard @ 2018-06-04 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604120540.5782-1-alexandre.belloni@bootlin.com>
On Mon, Jun 04, 2018 at 02:05:40PM +0200, Alexandre Belloni wrote:
> The IRQ is requested before the struct rtc is allocated and registered, but
> this struct is used in the IRQ handler. This may lead to a NULL pointer
> dereference.
>
> Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
> before requesting the IRQ.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180604/e4f3741d/attachment.sig>
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Niklas Söderlund @ 2018-06-04 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-9-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-29 17:05:59 +0200, Jacopo Mondi wrote:
> The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> driver and only confuse users. Remove them in all Gen2 SoC that use
> them.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
The more I think about this the more I lean towards that this patch
should be dropped. The properties accurately describes the hardware and
I think there is value in that. That the driver currently don't parse or
make use of them don't in my view reduce there value. Maybe you should
break out this patch to a separate series?
> ---
> v3:
> - remove bus-width from dt-bindings example
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
> arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> 7 files changed, 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 024c109..c6d7f60 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -128,7 +128,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 092610e..9cdabfcf 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -885,10 +885,8 @@
> port {
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -904,7 +902,6 @@
> port {
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 8ab793d..033c9e3 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -857,10 +857,8 @@
> port {
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -875,7 +873,6 @@
> port {
> vin1ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index a01101b..c16e870 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -388,7 +388,6 @@
> port {
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index aa209f6..60aaddb 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -765,10 +765,8 @@
> port {
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -784,7 +782,6 @@
> port {
> vin1ep: endpoint {
> remote-endpoint = <&adv7180_out>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index e170275..8ed7a71 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -388,7 +388,6 @@
> port {
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index 7808aae..6adfcd6 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -477,7 +477,6 @@
> port {
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH v3 6/8] dt-bindings: rcar-vin: Add 'hsync-as-de' custom prop
From: Niklas Söderlund @ 2018-06-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-7-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-29 17:05:57 +0200, Jacopo Mondi wrote:
> Document the boolean custom property 'renesas,hsync-as-de' that indicates
> that the HSYNC signal is internally used as data-enable, when the
> CLKENB signal is not connected.
>
> As this is a VIN specificity create a custom property specific to the R-Car
> VIN driver.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index ff53226..024c109 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -60,6 +60,9 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> - vsync-active: see [1] for description. Default is active high.
> - data-enable-active: polarity of CLKENB signal, see [1] for
> description. Default is active high.
> + - renesas,hsync-as-de: a boolean property to indicate that HSYNC signal
> + is internally used as data-enable when the CLKENB signal is
> + not available.
I'm not sure I like this, is there really a need to add a custom
property for this? The datasheet states that when the CLKENB pin is not
connected the driver should enable 'Clock Enable Hsync Select (CHS)'.
With the new generic property 'data-enable-active' which describes the
polarity of the CLKENB pin we also gain the knowledge if the CLKENB pin
is connected or not.
I propose we drop this custom property and instead let the driver check
if the CLKENB polarity is described or not and use that to determine if
CHS bit should be set or not. IMHO that is much simpler then having two
properties describing the same pin.
>
> If both HSYNC and VSYNC polarities are not specified, embedded
> synchronization is selected.
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH 5/7] iommu/dma: add support for non-strict mode
From: Leizhen (ThunderTown) @ 2018-06-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201806020106.eRUp2Ehc%fengguang.wu@intel.com>
On 2018/6/2 1:51, kbuild test robot wrote:
> Hi Zhen,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17-rc7 next-20180601]
> [cannot apply to iommu/next]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Zhen-Lei/add-non-strict-mode-support-for-arm-smmu-v3/20180602-000418
> config: x86_64-randconfig-x008-201821 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
> drivers//iommu/amd_iommu.c: In function 'amd_iommu_capable':
>>> drivers//iommu/amd_iommu.c:3053:2: warning: enumeration value 'IOMMU_CAP_NON_STRICT' not handled in switch [-Wswitch]
> switch (cap) {
> ^~~~~~
>
> vim +/IOMMU_CAP_NON_STRICT +3053 drivers//iommu/amd_iommu.c
>
> 645c4c8d arch/x86/kernel/amd_iommu.c Joerg Roedel 2008-12-02 3050
> ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3051 static bool amd_iommu_capable(enum iommu_cap cap)
> dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3052 {
> 80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 @3053 switch (cap) {
> 80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3054 case IOMMU_CAP_CACHE_COHERENCY:
> ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3055 return true;
> bdddadcb drivers/iommu/amd_iommu.c Joerg Roedel 2012-07-02 3056 case IOMMU_CAP_INTR_REMAP:
> ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3057 return (irq_remapping_enabled == 1);
> cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3058 case IOMMU_CAP_NOEXEC:
It seems that it's better to change this to 'default'.
> cfdeec22 drivers/iommu/amd_iommu.c Will Deacon 2014-10-27 3059 return false;
> 80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3060 }
> 80a506b8 arch/x86/kernel/amd_iommu.c Joerg Roedel 2010-07-27 3061
> ab636481 drivers/iommu/amd_iommu.c Joerg Roedel 2014-09-05 3062 return false;
> dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3063 }
> dbb9fd86 arch/x86/kernel/amd_iommu.c Sheng Yang 2009-03-18 3064
>
> :::::: The code at line 3053 was first introduced by commit
> :::::: 80a506b8fdcfa868bb53eb740f928217d0966fc1 x86/amd-iommu: Export cache-coherency capability
>
> :::::: TO: Joerg Roedel <joerg.roedel@amd.com>
> :::::: CC: Joerg Roedel <joerg.roedel@amd.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
--
Thanks!
BestRegards
^ permalink raw reply
* [PATCH v12 5/5] arm64: Allow huge io mappings again
From: Will Deacon @ 2018-06-04 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527856758-27169-6-git-send-email-cpandya@codeaurora.org>
On Fri, Jun 01, 2018 at 06:09:18PM +0530, Chintan Pandya wrote:
> Huge mappings have had stability issues due to stale
> TLB entry and memory leak issues. Since, those are
> addressed in this series of patches, it is now safe
> to allow huge mappings.
>
> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> ---
> arch/arm64/mm/mmu.c | 18 ++----------------
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 6e7e16c..c65abc4 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -934,15 +934,8 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
> {
> pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
> pgprot_val(mk_sect_prot(prot)));
> - pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot);
> -
> - /* Only allow permission changes for now */
> - if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)),
> - pud_val(new_pud)))
> - return 0;
Do you actually need to remove these checks? If we're doing
break-before-make properly, then the check won't fire but it would be
good to keep it there so we can catch misuse of these in future.
In other words, can we drop this patch?
Will
^ 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