* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Bjorn Helgaas @ 2017-12-12 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211104233.GB3225@red-moon>
On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > Fix child-node lookup during initialisation which was using the wrong
> > > OF-helper and ended up searching the whole device tree depth-first
> > > starting at the parent rather than just matching on its children.
> > >
> > > To make things worse, the parent pci node could end up being prematurely
> > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > Any matching child interrupt-controller node was also leaked.
> > >
> > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >
> > > v2
> > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > drops a reference to the start node
> > > - add Murali's and Lorenzo's acks
> >
> > This one hasn't shown up in linux-next, so sending a reminder to make
> > sure it doesn't fall between the cracks.
>
> Hi Johan,
>
> yes it is in the list of fixes to be sent upstream - I was about to
> ask Bjorn to apply it.
Is this something that needs to be merged for v4.15? If so, I need to
be able to defend it to Linus as being a critical fix. If the issue
been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
pretty "clear and present danger."
>From the commit log, I see a sub-optimal search (not critical), a
possible use-after-free (could conceivably be critical if people are
tripping over this, but would need more specifics about that), and a
leak (not critical).
Given what I can see now, my inclination would be for Lorenzo to queue
it for v4.16, which would still get in linux-next soonish.
Bjorn
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Rafael J. Wysocki @ 2017-12-12 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5024a041-2ef4-3912-994f-b5fcc945e916@arm.com>
On Tue, Dec 12, 2017 at 6:03 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 12/11/2017 07:11 PM, Rafael J. Wysocki wrote:
>>
>> On Friday, December 1, 2017 11:23:25 PM CET Jeremy Linton wrote:
>>>
>>> Add a entry to to struct cacheinfo to maintain a reference to the PPTT
>>> node which can be used to match identical caches across cores. Also
>>> stub out cache_setup_acpi() so that individual architectures can
>>> enable ACPI topology parsing.
>>>
>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>> ---
>>> drivers/acpi/pptt.c | 1 +
>>> drivers/base/cacheinfo.c | 20 ++++++++++++++------
>>> include/linux/cacheinfo.h | 13 ++++++++++++-
>>> 3 files changed, 27 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>>> index 0f8a1631af33..a35e457cefb7 100644
>>> --- a/drivers/acpi/pptt.c
>>> +++ b/drivers/acpi/pptt.c
>>> @@ -329,6 +329,7 @@ static void update_cache_properties(struct cacheinfo
>>> *this_leaf,
>>> {
>>> int valid_flags = 0;
>>> + this_leaf->firmware_node = cpu_node;
>>> if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
>>> this_leaf->size = found_cache->size;
>>> valid_flags++;
>>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>>> index eb3af2739537..ba89f9310e6f 100644
>>> --- a/drivers/base/cacheinfo.c
>>> +++ b/drivers/base/cacheinfo.c
>>> @@ -86,7 +86,10 @@ static int cache_setup_of_node(unsigned int cpu)
>>> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>> struct cacheinfo *sib_leaf)
>>> {
>>> - return sib_leaf->of_node == this_leaf->of_node;
>>> + if (acpi_disabled)
>>> + return sib_leaf->of_node == this_leaf->of_node;
>>> + else
>>> + return sib_leaf->firmware_node ==
>>> this_leaf->firmware_node;
>>> }
>>> /* OF properties to query for a given cache type */
>>> @@ -215,6 +218,11 @@ static inline bool cache_leaves_are_shared(struct
>>> cacheinfo *this_leaf,
>>> }
>>> #endif
>>> +int __weak cache_setup_acpi(unsigned int cpu)
>>> +{
>>> + return -ENOTSUPP;
>>> +}
>>> +
>>> static int cache_shared_cpu_map_setup(unsigned int cpu)
>>> {
>>> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>>> @@ -225,11 +233,11 @@ static int cache_shared_cpu_map_setup(unsigned int
>>> cpu)
>>> if (this_cpu_ci->cpu_map_populated)
>>> return 0;
>>> - if (of_have_populated_dt())
>>> + if (!acpi_disabled)
>>> + ret = cache_setup_acpi(cpu);
>>> + else if (of_have_populated_dt())
>>> ret = cache_setup_of_node(cpu);
>>> - else if (!acpi_disabled)
>>> - /* No cache property/hierarchy support yet in ACPI */
>>> - ret = -ENOTSUPP;
>>> +
>>> if (ret)
>>> return ret;
>>> @@ -286,7 +294,7 @@ static void cache_shared_cpu_map_remove(unsigned
>>> int cpu)
>>> static void cache_override_properties(unsigned int cpu)
>>> {
>>> - if (of_have_populated_dt())
>>> + if (acpi_disabled && of_have_populated_dt())
>>> return cache_of_override_properties(cpu);
>>> }
>>> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
>>> index 3d9805297cda..7ebff157ae6c 100644
>>> --- a/include/linux/cacheinfo.h
>>> +++ b/include/linux/cacheinfo.h
>>> @@ -37,6 +37,8 @@ enum cache_type {
>>> * @of_node: if devicetree is used, this represents either the cpu node
>>> in
>>> * case there's no explicit cache node or the cache node itself in
>>> the
>>> * device tree
>>> + * @firmware_node: When not using DT, this may contain pointers to other
>>> + * firmware based values. Particularly ACPI/PPTT unique values.
>>> * @disable_sysfs: indicates whether this node is visible to the user
>>> via
>>> * sysfs or not
>>> * @priv: pointer to any private data structure specific to particular
>>> @@ -65,8 +67,8 @@ struct cacheinfo {
>>> #define CACHE_ALLOCATE_POLICY_MASK \
>>> (CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
>>> #define CACHE_ID BIT(4)
>>> -
>>> struct device_node *of_node;
>>> + void *firmware_node;
>>
>>
>> What about converting this to using struct fwnode instead of adding
>> fields to it?
>
>
> I didn't really want to add another field here, but I've also pointed out
> how I thought converting it to a fwnode wasn't a good choice.
>
> https://lkml.org/lkml/2017/11/20/502
>
> Mostly because IMHO its even more misleading (lacking any fwnode_operations)
> than misusing the of_node as a void *.
I'm not sure what you mean.
Anyway, the idea is to have one pointer in there instead of two that
cannot be used at the same time and there's no reason why of_node
should be special.
of_node should just be one of multiple choices.
> Given that I'm in the minority thinking this, how far down the fwnode path
> on the ACPI side do we want to go?
I have no idea. :-)
> Is simply treating it as a void pointer
> sufficient for the ACPI side, considering all the PPTT code needs is a
> unique token?
I guess you can think about it as of_node under a different name, but
whether or not this is sufficient depends on what you need it for.
Thanks,
Rafael
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-12 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AftAWz339Sy+oxQ8K9Dr04Jyf8SV0R0JGrcPaL-VQLMQ@mail.gmail.com>
On Tue, Dec 12, 2017 at 02:56:18PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Tue, Dec 12, 2017 at 2:49 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > On the perhaps unlikely off-chance that it is both useful and welcome,
> > the (untested, probably does not even build) patch below illustrates the
> > use of smp_call_function_single(). This is based on the patch Russell
> > sent -- for all I know, it might well be that there are other places
> > needing similar changes.
> >
> > But something to try out for anyone wishing to do so.
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit c579a1494ccbc7ebf5548115571a2988ea1a1fe5
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Mon Dec 11 09:40:58 2017 -0800
> >
> > ARM: CPU hotplug: Delegate complete() to surviving CPU
> >
> > The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> > does so after RCU has stopped watching the outgoing CPU, which results
> > in lockdep complaints because complete() invokes functions containing RCU
> > readers. This patch therefore uses Thomas Gleixner's trick of delegating
> > the complete() call to a surviving CPU via smp_call_function_single().
> >
> > This patch is untested, and probably does not even build.
> >
> > Reported-by: Peng Fan <van.freenix@gmail.com>
> > Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> With your patch applied I no longer get the RCU warning, thanks:
>
> Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Well, I guess that it is no longer untested, and thank you for that. ;-)
I sent a more official posting of the patch.
Thanx, Paul
^ permalink raw reply
* [PATCH] ARM: CPU hotplug: Delegate complete() to surviving CPU
From: Paul E. McKenney @ 2017-12-12 17:20 UTC (permalink / raw)
To: linux-arm-kernel
The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
does so after RCU has stopped watching the outgoing CPU, which results
in lockdep complaints because complete() invokes functions containing RCU
readers. This patch therefore uses Thomas Gleixner's trick of delegating
the complete() call to a surviving CPU via smp_call_function_single().
Reported-by: Peng Fan <van.freenix@gmail.com>
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <linux-arm-kernel@lists.infradead.org>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00ee4ad..75f85e20aafa 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -267,6 +267,14 @@ void __cpu_die(unsigned int cpu)
}
/*
+ * Invoke complete() on behalf of the outgoing CPU.
+ */
+static void arch_cpu_idle_dead_complete(void *arg)
+{
+ complete(&cpu_died);
+}
+
+/*
* Called from the idle thread for the CPU which has been shutdown.
*
* Note that we disable IRQs here, but do not re-enable them
@@ -293,9 +301,11 @@ void arch_cpu_idle_dead(void)
/*
* Tell __cpu_die() that this CPU is now safe to dispose of. Once
* this returns, power and/or clocks can be removed at any point
- * from this CPU and its cache by platform_cpu_kill().
+ * from this CPU and its cache by platform_cpu_kill(). We cannot
+ * call complete() this late, so we delegate it to an online CPU.
*/
- complete(&cpu_died);
+ smp_call_function_single(cpumask_first(cpu_online_mask),
+ arch_cpu_idle_dead_complete, NULL, 0);
/*
* Ensure that the cache lines associated with that completion are
^ permalink raw reply related
* [PATCH] mmc: sdhci-of-arasan: Disable clk_xin clock in the remove
From: Flavio Ceolin @ 2017-12-12 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d975547-3f25-eaab-29fe-c06ee4cb206b@xilinx.com>
Hi Michal,
> On 12.12.2017 09:19, Flavio Ceolin wrote:
>> clk_xin is properly prepared/enabled on sdhci_arasan_probe(), and
>> unprepared/disabled in the error path, but it is not being
>> unprepared/disabled on sdhci_arasan_remove().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
>> ---
>> drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
>> index 0720ea7..69bd260 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -692,6 +692,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>> struct clk *clk_ahb = sdhci_arasan->clk_ahb;
>> + struct clk *clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
>
> I don't think this is right. You have already asked for this clock in
> probe. It means you should reuse pltfm_host->clk = clk_xin;
>
> And if you look at sdhci_pltfm_unregister you will find out that
> clk_disable_unprepare(pltfm_host->clk);
> is called there.
Yep, I confirm that. You're right, the patch is wrong, sorry for that :)
>
>>
>> if (!IS_ERR(sdhci_arasan->phy)) {
>> if (sdhci_arasan->is_phy_on)
>> @@ -705,6 +706,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
>>
>> clk_disable_unprepare(clk_ahb);
>>
>> + if (!IS_ERR(clk_xin))
>
> And clk_xin is required property.
>
>> + clk_disable_unprepare(clk_xin);
>> +
>> return ret;
>> }
>>
>>
>
> It means NACK from me.
>
> Thanks,
> Michal
Regards,
Flavio Ceolin
^ permalink raw reply
* [PATCH net-next v5 1/2] net: add support for Cavium PTP coprocessor
From: Richard Cochran @ 2017-12-12 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1e2faeb-ba5e-f324-efb5-da64e4b3ced3@cavium.com>
On Tue, Dec 12, 2017 at 12:41:35PM +0300, Aleksey Makarov wrote:
> If ptp_clock_register() returns NULL, the device is still paired with the driver,
> but the driver is not registered in the PTP core. When ethernet driver needs
> the reference to this cavium PTP driver, it calls cavium_ptp_get() that checks
> if ptp->ptp_clock is NULL and, if so, returns -ENODEV.
The pointer clock->ptp_clock can be NULL.
Yet you de-reference it here:
> +static void cavium_ptp_remove(struct pci_dev *pdev)
> +{
> + struct cavium_ptp *clock = pci_get_drvdata(pdev);
> + u64 clock_cfg;
> +
> + pci_set_drvdata(pdev, NULL);
> +
> + ptp_clock_unregister(clock->ptp_clock);
> +
> + clock_cfg = readq(clock->reg_base + PTP_CLOCK_CFG);
> + clock_cfg &= ~PTP_CLOCK_CFG_PTP_EN;
> + writeq(clock_cfg, clock->reg_base + PTP_CLOCK_CFG);
> +}
and here:
> +static inline int cavium_ptp_clock_index(struct cavium_ptp *clock)
> +{
> + return ptp_clock_index(clock->ptp_clock);
> +}
That needs to be fixed.
Thanks,
Richard
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Jeremy Linton @ 2017-12-12 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2078459.JrYtfXc8fv@aspire.rjw.lan>
Hi,
On 12/11/2017 07:11 PM, Rafael J. Wysocki wrote:
> On Friday, December 1, 2017 11:23:25 PM CET Jeremy Linton wrote:
>> Add a entry to to struct cacheinfo to maintain a reference to the PPTT
>> node which can be used to match identical caches across cores. Also
>> stub out cache_setup_acpi() so that individual architectures can
>> enable ACPI topology parsing.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/acpi/pptt.c | 1 +
>> drivers/base/cacheinfo.c | 20 ++++++++++++++------
>> include/linux/cacheinfo.h | 13 ++++++++++++-
>> 3 files changed, 27 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> index 0f8a1631af33..a35e457cefb7 100644
>> --- a/drivers/acpi/pptt.c
>> +++ b/drivers/acpi/pptt.c
>> @@ -329,6 +329,7 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
>> {
>> int valid_flags = 0;
>>
>> + this_leaf->firmware_node = cpu_node;
>> if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
>> this_leaf->size = found_cache->size;
>> valid_flags++;
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index eb3af2739537..ba89f9310e6f 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -86,7 +86,10 @@ static int cache_setup_of_node(unsigned int cpu)
>> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>> struct cacheinfo *sib_leaf)
>> {
>> - return sib_leaf->of_node == this_leaf->of_node;
>> + if (acpi_disabled)
>> + return sib_leaf->of_node == this_leaf->of_node;
>> + else
>> + return sib_leaf->firmware_node == this_leaf->firmware_node;
>> }
>>
>> /* OF properties to query for a given cache type */
>> @@ -215,6 +218,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>> }
>> #endif
>>
>> +int __weak cache_setup_acpi(unsigned int cpu)
>> +{
>> + return -ENOTSUPP;
>> +}
>> +
>> static int cache_shared_cpu_map_setup(unsigned int cpu)
>> {
>> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>> @@ -225,11 +233,11 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
>> if (this_cpu_ci->cpu_map_populated)
>> return 0;
>>
>> - if (of_have_populated_dt())
>> + if (!acpi_disabled)
>> + ret = cache_setup_acpi(cpu);
>> + else if (of_have_populated_dt())
>> ret = cache_setup_of_node(cpu);
>> - else if (!acpi_disabled)
>> - /* No cache property/hierarchy support yet in ACPI */
>> - ret = -ENOTSUPP;
>> +
>> if (ret)
>> return ret;
>>
>> @@ -286,7 +294,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
>>
>> static void cache_override_properties(unsigned int cpu)
>> {
>> - if (of_have_populated_dt())
>> + if (acpi_disabled && of_have_populated_dt())
>> return cache_of_override_properties(cpu);
>> }
>>
>> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
>> index 3d9805297cda..7ebff157ae6c 100644
>> --- a/include/linux/cacheinfo.h
>> +++ b/include/linux/cacheinfo.h
>> @@ -37,6 +37,8 @@ enum cache_type {
>> * @of_node: if devicetree is used, this represents either the cpu node in
>> * case there's no explicit cache node or the cache node itself in the
>> * device tree
>> + * @firmware_node: When not using DT, this may contain pointers to other
>> + * firmware based values. Particularly ACPI/PPTT unique values.
>> * @disable_sysfs: indicates whether this node is visible to the user via
>> * sysfs or not
>> * @priv: pointer to any private data structure specific to particular
>> @@ -65,8 +67,8 @@ struct cacheinfo {
>> #define CACHE_ALLOCATE_POLICY_MASK \
>> (CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
>> #define CACHE_ID BIT(4)
>> -
>> struct device_node *of_node;
>> + void *firmware_node;
>
> What about converting this to using struct fwnode instead of adding
> fields to it?
I didn't really want to add another field here, but I've also pointed
out how I thought converting it to a fwnode wasn't a good choice.
https://lkml.org/lkml/2017/11/20/502
Mostly because IMHO its even more misleading (lacking any
fwnode_operations) than misusing the of_node as a void *.
Given that I'm in the minority thinking this, how far down the fwnode
path on the ACPI side do we want to go? Is simply treating it as a void
pointer sufficient for the ACPI side, considering all the PPTT code
needs is a unique token?
>
>> bool disable_sysfs;
>> void *priv;
>> };
>> @@ -99,6 +101,15 @@ int func(unsigned int cpu) \
>> struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
>> int init_cache_level(unsigned int cpu);
>> int populate_cache_leaves(unsigned int cpu);
>> +int cache_setup_acpi(unsigned int cpu);
>> +int acpi_find_last_cache_level(unsigned int cpu);
>> +#ifndef CONFIG_ACPI
>> +int acpi_find_last_cache_level(unsigned int cpu)
>> +{
>> + /*ACPI kernels should be built with PPTT support*/
>> + return 0;
>> +}
>> +#endif
>>
>> const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
>>
>>
>
> Thanks,
> Rafael
>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Tony Lindgren @ 2017-12-12 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c92b0c2-8784-9c14-66b0-a19fe68f08ad@ti.com>
* Keerthy <j-keerthy@ti.com> [171212 08:25]:
>
>
> On Tuesday 12 December 2017 01:49 PM, Ladislav Michl wrote:
> > On Tue, Dec 12, 2017 at 01:38:04PM +0530, Keerthy wrote:
> >> On Tuesday 12 December 2017 01:31 PM, Ladislav Michl wrote:
> >>> On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
> >>>>
> >>>>
> >>>> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
> >>>>> Keerthy,
> >>>>>
> >>>>> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
> >>>>>> Remove all the unwanted exports from the driver
> >>>>>
> >>>>> I'm adding event capture capability to the pwm-omap driver and so far used
> >>>>> v4.15-rc3 as codebase.
> >>>>>
> >>>>> Intended use is an IR receiver; for that I need to measure pulses width and
> >>>>> spaces between pulses. So DM timer was setup to generate interupt after
> >>>>> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
> >>>>> TCAR_IT_FLAG is cleared.
> >>>>>
> >>>>> Of course, this is just proof of concept and needs to be polished and
> >>>>> generalized, but to make it at least work I need functions you just
> >>>>> unexported (plus some new).
> >>>>>
> >>>>> Question is whenever we need this level of indirection (omap_dm_timer_ops)
> >>>>> or plain exports are enough.
> >>>>
> >>>> The general guidance is not to do plain exports and go via
> >>>> omap_dm_timer_ops.
> >>>
> >>> ...in contrary what other clocksource drivers are doing.
Hmm what do you mean? We don't want to export tons of custom functions from
the timers in and then be in trouble when at some point we have a Linux
generic hw timer framework. We already had to deal with these custom
exports earlier with conversion to multiarch and then again with
device tree.
For now, it's best to pass the timer information to the pwm driver in
platform data. In the long run that will be much easier to deal with than
fixing random drivers tinkering with the timer registers directly.
> >>> Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
> >>> check for ops members to be assigned should be also extended or we should
> >>> delete it altogether and assume all members are populated?
> >>
> >> It should be fine to extend omap_dm_timer_ops. What are the ops missing
> >> for your new implementation?
> >
> > Read capture registers, configure capture and ack interrupt. Perhaps set_pwm
> > could be extended to configure capture as well.
> >
> > I'll update my code on top of your changes and we'll see how it would work.
Ideally the pwm driver would just do a request_irq from the dmtimer code
where dmtimer code would implement an interrupt controller. That would
be already most fo the Linux generic hardware timer framework right there :)
Regards,
Tony
^ permalink raw reply
* [PATCH 04/41] drm/rockchip: Respect page offset for PRIME mmap calls
From: Heiko Stuebner @ 2017-12-12 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170310043305.17216-5-seanpaul@chromium.org>
Hi,
Am Donnerstag, 9. M?rz 2017, 23:32:19 CET schrieb Sean Paul:
> From: ?rjan Eide <orjan.eide@arm.com>
>
> When mapping external DMA-bufs through the PRIME mmap call, we might be
> given an offset which has to be respected. However for the internal DRM
> GEM mmap path, we have to ignore the fake mmap offset used to identify
> the buffer only. Currently the code always zeroes out vma->vm_pgoff,
> which breaks the former.
>
> This patch fixes the problem by moving the vm_pgoff assignment to a
> function that is used only for GEM mmap path, so that the PRIME path
> retains the original offset.
>
> BUG=chrome-os-partner:56615
> TEST=graphics_GLBench
Unneeded chromeos-cruft.
> Cc: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: ?rjan Eide <orjan.eide@arm.com>
> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
With the same testas patch 3 (rk3328 + lima)
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-12 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVnFyFv0Q6PaBEb6RpfJYkSzpvNUy8XtEWczES+uEO=6Q@mail.gmail.com>
On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> >>> During userspace (Debian jessie NFS root) boot on arm64:
> >>>
> >>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
> >>> esr 0x92000004, in dash[aaaaadf77000+1a000]
> >>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> >>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> >>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
> >>> pstate: 80000000 (Nzcv daif -PAN -UAO)
> >>> pc : 0xaaaaadf8a51c
> >>> lr : 0xaaaaadf8ac08
> >>> sp : 0000ffffcffeac00
> >>> x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
> >>> x27: 0000ffffcffebf7c x26: 0000ffffcffead20
> >>> x25: 0000aaaacea1c5f0 x24: 0000000000000000
> >>> x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
> >>> x21: 0000000000000000 x20: 0000000000000008
> >>> x19: 0000000000000000 x18: 0000ffffcffeb500
> >>> x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
> >>> x15: 0000ffffa2363588 x14: ffffffffffffffff
> >>> x13: 0000000000000020 x12: 0000000000000010
> >>> x11: 0101010101010101 x10: 0000aaaaadfa1000
> >>> x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
> >>> x7 : 0000000000000000 x6 : 0000000000000000
> >>> x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
> >>> x3 : 0000aaaaadfa2338 x2 : 0000000000000000
> >>> x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
> >>>
> >>> Sometimes it happens with other processes, but the main address, esr, and
> >>> pstate values are always the same.
> >>>
> >>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> >>> releases, so the last time was two weeks ago), but never saw the issue
> >>> before until today, so probably v4.15-rc1 is OK.
> >>> Unfortunately it doesn't happen during every boot, which makes it
> >>> cumbersome to bisect.
> >>>
> >>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> >>> and even without today's arm64/for-next/core merged in, I still managed to
> >>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> >>> v4.15-rc3.
> >>
> >> Urgh, this looks nasty. Thanks for the report! A few questions:
> >>
> >> - Can you share your .config somewhere please?
> >
> > I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
> > renesas_defconfig (from Simon's repo).
>
> v4.15-rc2 is affected, too.
Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
reproduce this on any of our systems, unfortunately.
Will
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-12 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212164900.GA6673@linux.vnet.ibm.com>
Hi Paul,
On Tue, Dec 12, 2017 at 2:49 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On the perhaps unlikely off-chance that it is both useful and welcome,
> the (untested, probably does not even build) patch below illustrates the
> use of smp_call_function_single(). This is based on the patch Russell
> sent -- for all I know, it might well be that there are other places
> needing similar changes.
>
> But something to try out for anyone wishing to do so.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit c579a1494ccbc7ebf5548115571a2988ea1a1fe5
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Mon Dec 11 09:40:58 2017 -0800
>
> ARM: CPU hotplug: Delegate complete() to surviving CPU
>
> The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
> does so after RCU has stopped watching the outgoing CPU, which results
> in lockdep complaints because complete() invokes functions containing RCU
> readers. This patch therefore uses Thomas Gleixner's trick of delegating
> the complete() call to a surviving CPU via smp_call_function_single().
>
> This patch is untested, and probably does not even build.
>
> Reported-by: Peng Fan <van.freenix@gmail.com>
> Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
With your patch applied I no longer get the RCU warning, thanks:
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/2] cpufreq: sort the drivers in ARM part
From: Gregory CLEMENT @ 2017-12-12 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212165419.752-1-gregory.clement@free-electrons.com>
Keep the driver files alphabetically sorted.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/cpufreq/Makefile | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 812f9e0d01a3..d762e76887e7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
+obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
+obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
-obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
-obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
obj-$(CONFIG_ARM_S3C2440_CPUFREQ) += s3c2440-cpufreq.o
obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
+obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
obj-$(CONFIG_ARM_SA1100_CPUFREQ) += sa1100-cpufreq.o
obj-$(CONFIG_ARM_SA1110_CPUFREQ) += sa1110-cpufreq.o
@@ -81,8 +83,6 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
-obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
-obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
##################################################################################
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] cpufreq: ARM: sort the Kconfig menu
From: Gregory CLEMENT @ 2017-12-12 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212165419.752-1-gregory.clement@free-electrons.com>
Group all the related big LITTLE configuration together and sort the
other entries in alphabetic order.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/cpufreq/Kconfig.arm | 82 ++++++++++++++++++++++-----------------------
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index bdce4488ded1..0baf43837b51 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,6 +2,23 @@
# ARM CPU Frequency scaling drivers
#
+config ACPI_CPPC_CPUFREQ
+ tristate "CPUFreq driver based on the ACPI CPPC spec"
+ depends on ACPI_PROCESSOR
+ select ACPI_CPPC_LIB
+ default n
+ help
+ This adds a CPUFreq driver which uses CPPC methods
+ as described in the ACPIv5.1 spec. CPPC stands for
+ Collaborative Processor Performance Controls. It
+ is based on an abstract continuous scale of CPU
+ performance values which allows the remote power
+ processor to flexibly optimize for power and
+ performance. CPPC relies on power management firmware
+ support for its operation.
+
+ If in doubt, say N.
+
# big LITTLE core layer and glue drivers
config ARM_BIG_LITTLE_CPUFREQ
tristate "Generic ARM big LITTLE CPUfreq driver"
@@ -12,6 +29,30 @@ config ARM_BIG_LITTLE_CPUFREQ
help
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
+config ARM_DT_BL_CPUFREQ
+ tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && OF
+ help
+ This enables probing via DT for Generic CPUfreq driver for ARM
+ big.LITTLE platform. This gets frequency tables from DT.
+
+config ARM_SCPI_CPUFREQ
+ tristate "SCPI based CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
+ help
+ This adds the CPUfreq driver support for ARM big.LITTLE platforms
+ using SCPI protocol for CPU power management.
+
+ This driver uses SCPI Message Protocol driver to interact with the
+ firmware providing the CPU DVFS functionality.
+
+config ARM_VEXPRESS_SPC_CPUFREQ
+ tristate "Versatile Express SPC based CPUfreq driver"
+ depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
+ help
+ This add the CPUfreq driver support for Versatile Express
+ big.LITTLE platforms using SPC for power management.
+
config ARM_BRCMSTB_AVS_CPUFREQ
tristate "Broadcom STB AVS CPUfreq driver"
depends on ARCH_BRCMSTB || COMPILE_TEST
@@ -33,20 +74,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
If in doubt, say N.
-config ARM_DT_BL_CPUFREQ
- tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && OF
- help
- This enables probing via DT for Generic CPUfreq driver for ARM
- big.LITTLE platform. This gets frequency tables from DT.
-
-config ARM_VEXPRESS_SPC_CPUFREQ
- tristate "Versatile Express SPC based CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
- help
- This add the CPUfreq driver support for Versatile Express
- big.LITTLE platforms using SPC for power management.
-
config ARM_EXYNOS5440_CPUFREQ
tristate "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
@@ -205,16 +232,6 @@ config ARM_SA1100_CPUFREQ
config ARM_SA1110_CPUFREQ
bool
-config ARM_SCPI_CPUFREQ
- tristate "SCPI based CPUfreq driver"
- depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
- help
- This adds the CPUfreq driver support for ARM big.LITTLE platforms
- using SCPI protocol for CPU power management.
-
- This driver uses SCPI Message Protocol driver to interact with the
- firmware providing the CPU DVFS functionality.
-
config ARM_SPEAR_CPUFREQ
bool "SPEAr CPUFreq support"
depends on PLAT_SPEAR
@@ -275,20 +292,3 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
-
-config ACPI_CPPC_CPUFREQ
- tristate "CPUFreq driver based on the ACPI CPPC spec"
- depends on ACPI_PROCESSOR
- select ACPI_CPPC_LIB
- default n
- help
- This adds a CPUFreq driver which uses CPPC methods
- as described in the ACPIv5.1 spec. CPPC stands for
- Collaborative Processor Performance Controls. It
- is based on an abstract continuous scale of CPU
- performance values which allows the remote power
- processor to flexibly optimize for power and
- performance. CPPC relies on power management firmware
- support for its operation.
-
- If in doubt, say N.
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] cpufreq: Sort Kconfig and Makefile
From: Gregory CLEMENT @ 2017-12-12 16:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The patch of this series was originally part of the series "Add CPU
Frequency scaling support on Armada 37xx" [1].
As requested by Rafael J. Wysocki, these 2 patches are extracted in a
independent series, in the meantime, Viresh Kumar gave his acked-by
that I added to the patches.
Thanks,
Gregory
[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/546709.html
Gregory CLEMENT (2):
cpufreq: ARM: sort the Kconfig menu
cpufreq: sort the drivers in ARM part
drivers/cpufreq/Kconfig.arm | 82 ++++++++++++++++++++++-----------------------
drivers/cpufreq/Makefile | 8 ++---
2 files changed, 45 insertions(+), 45 deletions(-)
--
2.15.1
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171210213930.GL7829@linux.vnet.ibm.com>
On Sun, Dec 10, 2017 at 01:39:30PM -0800, Paul E. McKenney wrote:
> On Sun, Dec 10, 2017 at 07:34:39PM +0000, Russell King - ARM Linux wrote:
> > On Sun, Dec 10, 2017 at 11:07:27AM -0800, Paul E. McKenney wrote:
> > > On Sun, Dec 10, 2017 at 12:00:12PM +0000, Russell King - ARM Linux wrote:
> > > > +Paul
> > > >
> > > > Annoyingly, it looks like calling "complete()" from a dying CPU is
> > > > triggering the RCU usage warning. From what I remember, this is an
> > > > old problem, and we still have no better solution for this other than
> > > > to persist with the warning.
> > >
> > > I thought that this issue was resolved with tglx's use of IPIs from
> > > the outgoing CPU. Or is this due to an additional complete() from the
> > > ARM code? If so, could it also use tglx's IPI trick?
> >
> > I don't think it was tglx's IPI trick, I've had code sitting in my tree
> > for a while for it, but it has its own set of problems which are not
> > resolvable:
> >
> > 1. it needs more IPIs than we have available on all platforms
>
> OK, I will ask the stupid question... Is it possible to multiplex
> the IPIs, for example, by using smp_call_function_single()?
On the perhaps unlikely off-chance that it is both useful and welcome,
the (untested, probably does not even build) patch below illustrates the
use of smp_call_function_single(). This is based on the patch Russell
sent -- for all I know, it might well be that there are other places
needing similar changes.
But something to try out for anyone wishing to do so.
Thanx, Paul
------------------------------------------------------------------------
commit c579a1494ccbc7ebf5548115571a2988ea1a1fe5
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Dec 11 09:40:58 2017 -0800
ARM: CPU hotplug: Delegate complete() to surviving CPU
The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
does so after RCU has stopped watching the outgoing CPU, which results
in lockdep complaints because complete() invokes functions containing RCU
readers. This patch therefore uses Thomas Gleixner's trick of delegating
the complete() call to a surviving CPU via smp_call_function_single().
This patch is untested, and probably does not even build.
Reported-by: Peng Fan <van.freenix@gmail.com>
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00ee4ad..75f85e20aafa 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -267,6 +267,14 @@ void __cpu_die(unsigned int cpu)
}
/*
+ * Invoke complete() on behalf of the outgoing CPU.
+ */
+static void arch_cpu_idle_dead_complete(void *arg)
+{
+ complete(&cpu_died);
+}
+
+/*
* Called from the idle thread for the CPU which has been shutdown.
*
* Note that we disable IRQs here, but do not re-enable them
@@ -293,9 +301,11 @@ void arch_cpu_idle_dead(void)
/*
* Tell __cpu_die() that this CPU is now safe to dispose of. Once
* this returns, power and/or clocks can be removed at any point
- * from this CPU and its cache by platform_cpu_kill().
+ * from this CPU and its cache by platform_cpu_kill(). We cannot
+ * call complete() this late, so we delegate it to an online CPU.
*/
- complete(&cpu_died);
+ smp_call_function_single(cpumask_first(cpu_online_mask),
+ arch_cpu_idle_dead_complete, NULL, 0);
/*
* Ensure that the cache lines associated with that completion are
^ permalink raw reply related
* [PATCH v3 14/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl
From: Paolo Bonzini @ 2017-12-12 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211152226.GJ910@cbox>
On 11/12/2017 16:22, Christoffer Dall wrote:
> I find the special casing with the immediate return a bit ugly. Maybe
> introduce a helper async_vcpu_ioctl() or so that sets -ENOIOCTLCMD in
> its default case and return here if ret != -ENOIOCTLCMD? Christian,
> what do you think?
I'll post my attempt at it shortly.
Thanks,
Paolo
^ permalink raw reply
* [PATCH v3 11/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_guest_debug
From: Paolo Bonzini @ 2017-12-12 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211133943.236f18be.cohuck@redhat.com>
On 11/12/2017 13:39, Cornelia Huck wrote:
>> + ret = -EINVAL;
>> for (n = 0; n < (KVMPPC_BOOKE_IAC_NUM + KVMPPC_BOOKE_DAC_NUM); n++) {
>> uint64_t addr = dbg->arch.bp[n].addr;
>> uint32_t type = dbg->arch.bp[n].type;
>> @@ -2067,21 +2071,24 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>> if (type & ~(KVMPPC_DEBUG_WATCH_READ |
>> KVMPPC_DEBUG_WATCH_WRITE |
>> KVMPPC_DEBUG_BREAKPOINT))
>> - return -EINVAL;
>> + goto out;
>>
>> if (type & KVMPPC_DEBUG_BREAKPOINT) {
>> /* Setting H/W breakpoint */
>> if (kvmppc_booke_add_breakpoint(dbg_reg, addr, b++))
>> - return -EINVAL;
>> + goto out;
>> } else {
>> /* Setting H/W watchpoint */
>> if (kvmppc_booke_add_watchpoint(dbg_reg, addr,
>> type, w++))
>> - return -EINVAL;
>> + goto out;
>> }
>> }
>>
>> - return 0;
>> + ret = 0;
>
> I would probably set the -EINVAL in the individual branches (so it is
> clear that something is wrong, and it is not just a benign exit as in
> the cases above), but your code is correct as well. Let the powerpc
> folks decide.
The idiom that Christoffer used is found elsewhere in KVM, so I'm
accepting his version. Thanks for the review!
Paolo
^ permalink raw reply
* [PATCH v3 07/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs
From: Paolo Bonzini @ 2017-12-12 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211091921.GE910@cbox>
On 11/12/2017 10:19, Christoffer Dall wrote:
> On Fri, Dec 08, 2017 at 05:26:02PM +0100, David Hildenbrand wrote:
>>
>>>
>>> int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>>> index f647e121070e..cdf0be02c95a 100644
>>> --- a/arch/powerpc/kvm/booke.c
>>> +++ b/arch/powerpc/kvm/booke.c
>>> @@ -1632,18 +1632,25 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>> {
>>> int ret;
>>>
>>> + vcpu_load(vcpu);
>>> +
>>> + ret = -EINVAL;
>>
>> you can initialize this directly.
>>
>>> if (vcpu->arch.pvr != sregs->pvr)
>>> - return -EINVAL;
>>> + goto out;
>>>
>>> ret = set_sregs_base(vcpu, sregs);
>>> if (ret < 0)
>>> - return ret;
>>> + goto out;
>>>
>>> ret = set_sregs_arch206(vcpu, sregs);
>>> if (ret < 0)
>>> - return ret;
>>> + goto out;
>>> +
>>> + ret = vcpu->kvm->arch.kvm_ops->set_sregs(vcpu, sregs);
>>>
>>> - return vcpu->kvm->arch.kvm_ops->set_sregs(vcpu, sregs);
>>> +out:
>>> + vcpu_put(vcpu);
>>> + return ret;
>>> }
>>>
>>> int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index 18011fc4ac49..d95b4f15e52b 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> @@ -2729,8 +2729,12 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>>> int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>> struct kvm_sregs *sregs)
>>> {
>>> + vcpu_load(vcpu);
>>> +
>>> memcpy(&vcpu->run->s.regs.acrs, &sregs->acrs, sizeof(sregs->acrs));
>>> memcpy(&vcpu->arch.sie_block->gcr, &sregs->crs, sizeof(sregs->crs));
>>> +
>>> + vcpu_put(vcpu);
>>> return 0;
>>> }
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 20a5f6776eea..a31a80aee0b9 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -7500,15 +7500,19 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>>> int mmu_reset_needed = 0;
>>> int pending_vec, max_bits, idx;
>>> struct desc_ptr dt;
>>> + int ret;
>>> +
>>> + vcpu_load(vcpu);
>>>
>>> + ret = -EINVAL;
>>
>> dito
>
> Sure.
I'm doing it when applying.
Paolo
>> Reviewed-by: David Hildenbrand <david@redhat.com>
^ permalink raw reply
* [VDSO]: vdso_test failing on arm 32 bit
From: Russell King - ARM Linux @ 2017-12-12 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLiiV=8xy+Fr3fqtsGWrJmCYPzzTDZSySntXZwHtonDobw@mail.gmail.com>
On Tue, Dec 12, 2017 at 09:49:42PM +0530, Pintu Kumar wrote:
> Hi All,
>
> Did anybody tried running vdso_test (under Documentation/vDSO in
> kernel 4.1) on an ARM 32 bit system?
>
> When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this:
> # ./vdso_test
> Could not find __vdso_gettimeofday
>
> When I check more in parse_vdso.c, I found that under vdso_sym
> function, sym->st_name is returning 0 for the first time, and next it
> returns value 54, then exit and finally vdso_sym returning 0.
> So, its not able to parse the gettimeofday symbol from the ELF header.
> When I check arch/arm/kernel/vdso.so, the symbol is present.
>
> I even tried for clock_gettime, and even this is also failing.
>
> Note: the same test is working fine on Ubuntu 16.04 (64 bit), when
> compiled with both 32 bit and 64 bit version.
> Even, the test is working on ARM 64 bit.
>
> If anybody is aware, please let me know if vdso_test is supported on
> ARM 32 bit system or not?
The vdso time functions are only useful if you have an architected timer.
If you don't have one, the time functions are useless and there's little
point in making them available via the vdso.
--
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 v6] atmel_flexcom: Support resuming after a chip reset
From: Romain Izard @ 2017-12-12 16:21 UTC (permalink / raw)
To: linux-arm-kernel
The controller used by a flexcom module is configured at boot, and left
alone after this. In the suspend mode called "backup with self-refresh"
available on SAMA5D2, the chip will resume with most of its registers
reset. In this case, we need to restore the state of the flexcom driver
on resume.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
---
Changes in v5:
* extract from the patch series, and send as a standalone patch
Changes in v6:
* Reword the patch title and description
* Rename the internal structure to ddata
drivers/mfd/atmel-flexcom.c | 63 ++++++++++++++++++++++++++++++++++-----------
1 file changed, 48 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/atmel-flexcom.c b/drivers/mfd/atmel-flexcom.c
index 064bde9cff5a..f684a93a3340 100644
--- a/drivers/mfd/atmel-flexcom.c
+++ b/drivers/mfd/atmel-flexcom.c
@@ -39,34 +39,43 @@
#define FLEX_MR_OPMODE(opmode) (((opmode) << FLEX_MR_OPMODE_OFFSET) & \
FLEX_MR_OPMODE_MASK)
+struct atmel_flexcom {
+ void __iomem *base;
+ u32 opmode;
+ struct clk *clk;
+};
static int atmel_flexcom_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct clk *clk;
struct resource *res;
- void __iomem *base;
- u32 opmode;
+ struct atmel_flexcom *ddata;
int err;
- err = of_property_read_u32(np, "atmel,flexcom-mode", &opmode);
+ ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ err = of_property_read_u32(np, "atmel,flexcom-mode", &ddata->opmode);
if (err)
return err;
- if (opmode < ATMEL_FLEXCOM_MODE_USART ||
- opmode > ATMEL_FLEXCOM_MODE_TWI)
+ if (ddata->opmode < ATMEL_FLEXCOM_MODE_USART ||
+ ddata->opmode > ATMEL_FLEXCOM_MODE_TWI)
return -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
+ ddata->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(ddata->base))
+ return PTR_ERR(ddata->base);
- clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(clk))
- return PTR_ERR(clk);
+ ddata->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(ddata->clk))
+ return PTR_ERR(ddata->clk);
- err = clk_prepare_enable(clk);
+ err = clk_prepare_enable(ddata->clk);
if (err)
return err;
@@ -76,9 +85,9 @@ static int atmel_flexcom_probe(struct platform_device *pdev)
* inaccessible and are read as zero. Also the external I/O lines of the
* Flexcom are muxed to reach the selected device.
*/
- writel(FLEX_MR_OPMODE(opmode), base + FLEX_MR);
+ writel(FLEX_MR_OPMODE(ddata->opmode), ddata->base + FLEX_MR);
- clk_disable_unprepare(clk);
+ clk_disable_unprepare(ddata->clk);
return devm_of_platform_populate(&pdev->dev);
}
@@ -89,10 +98,34 @@ static const struct of_device_id atmel_flexcom_of_match[] = {
};
MODULE_DEVICE_TABLE(of, atmel_flexcom_of_match);
+#ifdef CONFIG_PM_SLEEP
+static int atmel_flexcom_resume(struct device *dev)
+{
+ struct atmel_flexcom *ddata = dev_get_drvdata(dev);
+ int err;
+ u32 val;
+
+ err = clk_prepare_enable(ddata->clk);
+ if (err)
+ return err;
+
+ val = FLEX_MR_OPMODE(ddata->opmode),
+ writel(val, ddata->base + FLEX_MR);
+
+ clk_disable_unprepare(ddata->clk);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(atmel_flexcom_pm_ops, NULL,
+ atmel_flexcom_resume);
+
static struct platform_driver atmel_flexcom_driver = {
.probe = atmel_flexcom_probe,
.driver = {
.name = "atmel_flexcom",
+ .pm = &atmel_flexcom_pm_ops,
.of_match_table = atmel_flexcom_of_match,
},
};
--
2.14.1
^ permalink raw reply related
* [VDSO]: vdso_test failing on arm 32 bit
From: Pintu Kumar @ 2017-12-12 16:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
Did anybody tried running vdso_test (under Documentation/vDSO in
kernel 4.1) on an ARM 32 bit system?
When I test it on iMX.7 board (kernel 4.1, ARM 32 bit), I get this:
# ./vdso_test
Could not find __vdso_gettimeofday
When I check more in parse_vdso.c, I found that under vdso_sym
function, sym->st_name is returning 0 for the first time, and next it
returns value 54, then exit and finally vdso_sym returning 0.
So, its not able to parse the gettimeofday symbol from the ELF header.
When I check arch/arm/kernel/vdso.so, the symbol is present.
I even tried for clock_gettime, and even this is also failing.
Note: the same test is working fine on Ubuntu 16.04 (64 bit), when
compiled with both 32 bit and 64 bit version.
Even, the test is working on ARM 64 bit.
If anybody is aware, please let me know if vdso_test is supported on
ARM 32 bit system or not?
Thanks,
Pintu
^ permalink raw reply
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: Jeremy Linton @ 2017-12-12 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9009154.M66RGdQJXA@aspire.rjw.lan>
Hi,
First, thanks for taking a look at this.
On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
>> The PPTT can be used to determine the groupings of CPU's at
>> given levels in the system. Lets add a few routines to the PPTT
>> parsing code to return a unique id for each unique level in the
>> processor hierarchy. This can then be matched to build
>> thread/core/cluster/die/package/etc mappings for each processing
>> element in the system.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>
> Why can't this be folded into patch [2/9]?
It can, and I will be happy squash it.
It was requested that the topology portion of the parser be split out
back in v3.
https://www.spinics.net/lists/linux-acpi/msg78487.html
^ permalink raw reply
* [PATCH] ARM: verify size of zImage
From: Gregory CLEMENT @ 2017-12-12 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-oXSpUcJ6acBKyohQ3WxSDp3sK7A4No2y4CHCFw1kSaQ@mail.gmail.com>
Hi Ard,
On mar., nov. 28 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> (+ Gregory)
>
> On 28 November 2017 at 16:27, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>> The linker can sometimes add additional sections to the zImage ELF file
>> which results in the zImage binary being larger than expected. This
>> causes appended DT blobs to fail.
>>
>> Verify that the zImage binary is the expected size, and fail the build
>> if this is not the case.
>>
>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>> ---
>> As this patch is different, I've dropped Matthias' tested-by. I'd
>> appreciate a replacement, thanks. Also, I seem to remember that
>> Ard's toolchain was giving issues - maybe this alternative will
>> finally resolve them.
>>
>
> $ nm arch/arm/boot/compressed/vmlinux |grep _edata
> 007b8200 D _edata
> 007b8200 D _edata_real
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> although I don't remember seeing this fail. It think it may have been
> Gregory who was having these issues?
Thanks to remember me, I finally find time to test it, and with my setup
I didn't have anymore issue while building it for a dtb append zImage
for Armada XP:
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
>
>
>
>> arch/arm/boot/compressed/vmlinux.lds.S | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
>> index e6bf6774c4bb..ed53ca9f482e 100644
>> --- a/arch/arm/boot/compressed/vmlinux.lds.S
>> +++ b/arch/arm/boot/compressed/vmlinux.lds.S
>> @@ -101,6 +101,12 @@ SECTIONS
>> * this symbol allows further debug in the near future.
>> */
>> .image_end (NOLOAD) : {
>> + /*
>> + * EFI requires that the image is aligned to 512 bytes, and appended
>> + * DTB requires that we know where the end of the image is. Ensure
>> + * that both are satisfied by ensuring that there are no additional
>> + * sections emitted into the decompressor image.
>> + */
>> _edata_real = .;
>> }
>>
>> @@ -128,3 +134,4 @@ SECTIONS
>> .stab.indexstr 0 : { *(.stab.indexstr) }
>> .comment 0 : { *(.comment) }
>> }
>> +ASSERT(_edata_real == _edata, "error: zImage file size is incorrect");
>> --
>> 2.7.4
>>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-12 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVoqyWU3SRJ3zSdNNf_pJz9t_9fNYZ2EQr4JECTHRREJQ@mail.gmail.com>
Hi Will,
On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
>>> During userspace (Debian jessie NFS root) boot on arm64:
>>>
>>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
>>> esr 0x92000004, in dash[aaaaadf77000+1a000]
>>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
>>> pstate: 80000000 (Nzcv daif -PAN -UAO)
>>> pc : 0xaaaaadf8a51c
>>> lr : 0xaaaaadf8ac08
>>> sp : 0000ffffcffeac00
>>> x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
>>> x27: 0000ffffcffebf7c x26: 0000ffffcffead20
>>> x25: 0000aaaacea1c5f0 x24: 0000000000000000
>>> x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
>>> x21: 0000000000000000 x20: 0000000000000008
>>> x19: 0000000000000000 x18: 0000ffffcffeb500
>>> x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
>>> x15: 0000ffffa2363588 x14: ffffffffffffffff
>>> x13: 0000000000000020 x12: 0000000000000010
>>> x11: 0101010101010101 x10: 0000aaaaadfa1000
>>> x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
>>> x7 : 0000000000000000 x6 : 0000000000000000
>>> x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
>>> x3 : 0000aaaaadfa2338 x2 : 0000000000000000
>>> x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>>>
>>> Sometimes it happens with other processes, but the main address, esr, and
>>> pstate values are always the same.
>>>
>>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>>> releases, so the last time was two weeks ago), but never saw the issue
>>> before until today, so probably v4.15-rc1 is OK.
>>> Unfortunately it doesn't happen during every boot, which makes it
>>> cumbersome to bisect.
>>>
>>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>>> and even without today's arm64/for-next/core merged in, I still managed to
>>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>>> v4.15-rc3.
>>
>> Urgh, this looks nasty. Thanks for the report! A few questions:
>>
>> - Can you share your .config somewhere please?
>
> I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
> renesas_defconfig (from Simon's repo).
v4.15-rc2 is affected, too.
>> - What was your last known-good kernel?
>
> v4.15-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API
From: Georgi Djakov @ 2017-12-12 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHLCerOgm+T6S1pxjo5hFajyU+vqUgBFcwfuBCsphgECRMf3Yw@mail.gmail.com>
Hi Amit,
On 12/08/2017 08:38 PM, Amit Kucheria wrote:
> On Fri, Sep 8, 2017 at 10:48 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
>> This patch introduce a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
[..]
>> +inline int interconnect_set(struct interconnect_path *path,
>> + struct interconnect_creq *creq);
>
> Remove the semi colon
Thanks! Fixed.
>
>> +{
>> + return -ENOTSUPP
>
> return ERR_PTR(-ENOTSUPP);
I do not agree here. It should be left as is, because the function
returns int.
>
>> +}
>> +
>
> This breaks the build with INTERCONNECT disabled in Kconfig.
Ok, i have fixed this as well.
Thanks,
Georgi
^ 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