* [PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Sudeep Holla @ 2018-01-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110144631.GE3626@vireshk-i7>
On 10/01/18 14:46, Viresh Kumar wrote:
> On 09-01-18, 16:49, Sudeep Holla wrote:
>> The dependency on physical_package_id from the topology to get the
>> cluster identifier is wrong. The concept of cluster used in ARM topology
>> is unfortunately not well defined in the architecture, we should avoid
>> using it. Further the frequency domain need not be mapped to so called
>> "clusters" one to one.
>>
>> SCPI already provides means to obtain the frequency domain id from the
>> device tree. In order to support some new topologies(e.g. DSU which
>> contains 2 frequency domains within the physical cluster), pseudo
>> clusters are created to make this driver work which is wrong again.
>>
>> In order to solve those issues and also remove dependency of topological
>> physical id for frequency domain, this patch removes the arm_big_little
>> dependency from scpi driver.
>>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/cpufreq/scpi-cpufreq.c | 193 +++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 178 insertions(+), 15 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
Thanks :)
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 27/33] dma-direct: use node local allocations for coherent memory
From: Robin Murphy @ 2018-01-10 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110153017.GD17790@lst.de>
On 10/01/18 15:30, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:06:22PM +0000, Robin Murphy wrote:
>> On 10/01/18 08:00, Christoph Hellwig wrote:
>>> To preserve the x86 behavior.
>>
>> And combined with patch 10/22 of the SWIOTLB refactoring, this means
>> SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what
>> we want on arm64 too :)
>
> Well, only for swiotlb allocations that can be satisfied by
> dma_direct_alloc. If we actually have to fall back to the swiotlb
> buffers there is not node affinity yet.
Yeah, when I looked into it I reached the conclusion that per-node
bounce buffers probably weren't worth it - if you have to bounce you've
already pretty much lost the performance game, and if the CPU doing the
bouncing happens to be on a different node from the device you've
certainly lost either way. Per-node CMA zones we definitely *would*
like, but that's a future problem (it looks technically feasible without
huge infrastructure changes, but fiddly).
Robin.
^ permalink raw reply
* [PATCH v2 0/6] ARM branch predictor hardening
From: Nishanth Menon @ 2018-01-10 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108185533.9698-1-marc.zyngier@arm.com>
On 01/08/2018 12:55 PM, Marc Zyngier wrote:
> This small series implements some basic BP hardening by invalidating
> the BTB on CPUs that are known to be susceptible to aliasing attacks.
>
> These patches are closely modelled against what we do on arm64,
> although simpler as we can rely on an architected instruction to
> perform the invalidation. The notable exception is Cortex-A15, where
> BTB invalidation behaves like a NOP, and the only way to shoot the
> predictor down is to invalidate the icache *and* to have ACTLR[0] set
> to 1 (which is a secure-only operation).
>
btw, just wanted to understand if we had any reasons as to why
we'arent tagging these for stable? Yes, I am aware of Greg's comments
in [1], but the v7 series impacts a heck of a lot of existing products
and is not that extensive to cause too much of a pain is it?
OR, am I missing some thing else?
[1] http://www.kroah.com/log/blog/2018/01/06/meltdown-status/
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 0/2] 2c: mv64xxx: Fix clock resource for Armada 7K/8K
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This short series fixes the way the clocks are used for the mv64xxx
controller embedded in the Marvell Armada 7K/8K SoCs. On these SoCs a
second one is needed in order to clock the registers. It was not
noticed until now because we relied on the bootloader and also because
the clock driver was wrong.
Thanks to this fix, it would be possible to fix the clock driver
without introducing a regression.
The first patch is just a small cleanup found when I wrote the main
patch.
Thanks,
Gregory
Gregory CLEMENT (2):
i2c: mv64xxx: Remove useless test before clk_disable_unprepare
i2c: mv64xxx: Fix clock resource by adding an optional bus clock
drivers/i2c/busses/i2c-mv64xxx.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] i2c: mv64xxx: Remove useless test before clk_disable_unprepare
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-1-gregory.clement@free-electrons.com>
The 2 functions called from clk_disable_unprepare() already check that
the clock pointer is valid: no need to test it before calling it.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index a832c45276a4..f69066266faa 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -950,9 +950,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return rc;
}
@@ -965,9 +963,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return 0;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-1-gregory.clement@free-electrons.com>
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.
The binding documentation is updating accordingly.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index f69066266faa..cce37d8ecf41 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -135,6 +135,7 @@ struct mv64xxx_i2c_data {
u32 freq_m;
u32 freq_n;
struct clk *clk;
+ struct clk *axi_clk;
wait_queue_head_t waitq;
spinlock_t lock;
struct i2c_msg *msg;
@@ -894,13 +895,20 @@ mv64xxx_i2c_probe(struct platform_device *pd)
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
- /* Not all platforms have a clk */
+ /* Not all platforms have clocks */
drv_data->clk = devm_clk_get(&pd->dev, NULL);
if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR(drv_data->clk))
clk_prepare_enable(drv_data->clk);
+ drv_data->axi_clk = devm_clk_get(&pd->dev, "axi");
+ if (IS_ERR(drv_data->axi_clk) &&
+ PTR_ERR(drv_data->axi_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!IS_ERR(drv_data->axi_clk))
+ clk_prepare_enable(drv_data->axi_clk);
+
drv_data->irq = platform_get_irq(pd, 0);
if (pdata) {
@@ -950,6 +958,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return rc;
@@ -963,6 +972,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return 0;
--
2.15.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx6ul-evk: Add support for mag3110 sensor
From: Fabio Estevam @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-1-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 6UL EVK has a MAG3110 Magnetometer sensor in its base board.
> Add support for this sensor, which is included in the trivial i2c devices
> and according to the bindings documentation, just need a compatible field
> and an address.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/3] ARM: imx: Update imx_v6_v7_defconfig for mag3110 support
From: Fabio Estevam @ 2018-01-10 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-2-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 6UL EVK has support for the MAG3110 Magnetometer sensor, included
> in its base board by default.
>
> So add support for this Magnetometer in the imx_v6_v7_defconfig.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx7d-sdb: Add support for mpl3115 sensor
From: Fabio Estevam @ 2018-01-10 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-3-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 7D SDB has a MPL3115 Pressure sensor.
> Add support for this sensor, which is included in the trivial i2c devices
> and according to the bindings documentation, just need a compatible field
> and an address.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Thomas Petazzoni @ 2018-01-10 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-3-gregory.clement@free-electrons.com>
Hello,
On Wed, 10 Jan 2018 17:51:47 +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
>
> The binding documentation is updating accordingly.
Seems like the binding documentation update is not part of this patch :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 00/12] firmware: arm_scpi: series with smaller improvements
From: Sudeep Holla @ 2018-01-10 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99220c79-8b35-2978-11d1-6d101ccb6772@gmail.com>
Hi Heiner,
(Sorry for the late response, was off for a month)
On 05/12/17 21:54, Heiner Kallweit wrote:
> After recent revert of all changes since 4.14 this is a resubmit of
> the patch series, reduced to patches which should not cause any
> regression.
> Based on a remark from Kevin I added one patch for improving the
> version info for pre-1.0 firmware that doesn't provide version
> information.
>
> Best should be to apply it to a devel branch first so that the
> Baylibre Amlogic team can test before mainlining.
>
I am still waiting for tested by from Amlogic team for this series.
However I prefer even the patch you dropped as causing the issue to
be tested as it's nice cleanup to have. I strongly think that the issue
Kevin reported was due to broken DVFS in the scp firmware in which case
the solution is to have the dvfs node in DT removed or disabled rather
than not having that patch at all.
Please post that patch on rebased on top of this series and get it
tested with DVFS nodes disabled.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 0/3] ARM branch predictor hardening
From: Russell King - ARM Linux @ 2018-01-10 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86608c3urn.wl-marc.zyngier@arm.com>
On Mon, Jan 08, 2018 at 09:28:28PM +0000, Marc Zyngier wrote:
> On Sat, 06 Jan 2018 18:50:41 +0000,
> Florian Fainelli wrote:
>
> Hi Florian,
>
> > Le 01/06/18 ? 04:09, Marc Zyngier a ?crit?:
> > > This small series implements some basic BP hardening by invalidating
> > > the BTB on CPUs that are known to be susceptible to aliasing attacks.
> > >
> > > These patches are closely modelled against what we do on arm64,
> > > although simpler as we can rely on an architected instruction to
> > > perform the invalidation.
> > >
> > > The first patch reuses the Cortex-A8 BTB invalidation in switch_mm and
> > > generalises it to be used on all affected CPUs. The second perform the
> > > same invalidation on fatal signal delivery. The last one nukes it on
> > > guest exit, and results in some major surgery (kudos to Dimitris
> > > Papastamos who came up with the magic vector decoding sequence).
> > >
> > > Note that that M-class CPUs are not affected and for R-class cores,
> > > the mitigation doesn't make much sense since we do not enforce
> > > user/kernel isolation.
> >
> > Broadcom's Brahma-B15 CPUs are also affected, I can either send an
> > incremental patch on top of this series once it lands in, or since it
> > looks like you are going to respin a v2, feel free to incorporate the
> > changes I sent as replies to patch 1 and 2.
>
> I've re-spun the series, as there was quite a few issues with the
> first one. Could you please try and respin your B15 patches on top?
>
> > What about P4JB and Krait, should they also be covered?
>
> I have no idea. I only know of the ARM cores. Other implementation
> will have to check whether they are affected or not.
>
> > Even though I am assuming -stable maintainers will quickly pick
> > those changes, should there be an explicit mention of CVE-2017-5715?
>
> I have no plans for these patches to be merged immediately. We're
> targeting the arm64 patches at v4.16, and I don't expect the 32bit
> patches to be any different.
>
> As for the CVE mention, I'm not really bothered (yet another number
> soup). Everybody knows what we're talking about, these days...
That is untrue. I've been trying to talk to you guys about it, and
I'm getting very little back - you haven't replied to the email I sent
privately last week for example, and so far I've not seen any response
to my email yesterday.
So for the past week, I've been researching the information and trying
stuff out. I've my own conclusions, reached entirely independently,
and so far I see nothing to suggest that this patch series does anything
to solve any of the published issues.
Given that, I'm not currently considering merging these patches until
it becomes clearer what they are trying to address.
--
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 31/33] dma-direct: reject too small dma masks
From: Robin Murphy @ 2018-01-10 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110153226.GE17790@lst.de>
On 10/01/18 15:32, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 11:49:34AM +0000, Robin Murphy wrote:
>>> +#ifdef CONFIG_ZONE_DMA
>>> + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>>> + return 0;
>>> +#else
>>> + /*
>>> + * Because 32-bit DMA masks are so common we expect every architecture
>>> + * to be able to satisfy them - either by not supporting more physical
>>> + * memory, or by providing a ZONE_DMA32. If neither is the case, the
>>> + * architecture needs to use an IOMMU instead of the direct mapping.
>>> + */
>>> + if (mask < DMA_BIT_MASK(32))
>>> + return 0;
>>
>> Do you think it's worth the effort to be a little more accommodating here?
>> i.e.:
>>
>> return dma_max_pfn(dev) >= max_pfn;
>>
>> We seem to have a fair few 28-31 bit masks for older hardware which
>> probably associates with host systems packing equivalently small amounts of
>> RAM.
>
> And those devices don't have a ZONE_DMA? I think we could do something
> like that, but I'd rather have it as a separate commit with a good
> explanation. Maybe you can just send on on top of the series?
Good point - other than the IXP4xx platform and possibly the Broadcom
network drivers, it's probably only x86-relevant stuff where the concern
is moot. Let's just keep the simple assumption then, until actually
proven otherwise.
Robin.
^ permalink raw reply
* [PATCH 10/22] swiotlb: refactor coherent buffer allocation
From: Robin Murphy @ 2018-01-10 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110154649.GA18529@lst.de>
On 10/01/18 15:46, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:22:18PM +0000, Robin Murphy wrote:
>>> + if (phys_addr == SWIOTLB_MAP_ERROR)
>>> + goto out_warn;
>>> - /* Confirm address can be DMA'd by device */
>>> - if (dev_addr + size - 1 > dma_mask) {
>>> - printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
>>> - (unsigned long long)dma_mask,
>>> - (unsigned long long)dev_addr);
>>> + *dma_handle = swiotlb_phys_to_dma(dev, phys_addr);
>>
>> nit: this should probably go after the dma_coherent_ok() check (as with the
>> original logic).
>
> But the originall logic also needs the dma_addr_t for the
> dma_coherent_ok check:
>
> dev_addr = swiotlb_phys_to_dma(hwdev, paddr);
> /* Confirm address can be DMA'd by device */
> if (dev_addr + size - 1 > dma_mask) {
> ...
> goto err_warn;
> }
>
> or do you mean assining to *dma_handle? The dma_handle is not
> valid for a failure return, so I don't think this should matter.
Yeah, only the assignment - as I said, it's just a stylistic nit; no big
deal either way.
>>> + if (ret) {
>>> + *dma_handle = swiotlb_virt_to_bus(hwdev, ret);
>>> + if (dma_coherent_ok(hwdev, *dma_handle, size)) {
>>> + memset(ret, 0, size);
>>> + return ret;
>>> + }
>>
>> Aren't we leaking the pages here?
>
> Yes, that free_pages got lost somewhere in the rebases, I've added
> it back.
Cool.
Robin.
^ permalink raw reply
* [PATCH 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110175407.2185e95c@windsurf.lan>
Hi Thomas,
On mer., janv. 10 2018, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 10 Jan 2018 17:51:47 +0100, Gregory CLEMENT wrote:
>> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
>> is optional because not all the SoCs need them but at least for Armada
>> 7K/8K it is actually mandatory.
>>
>> The binding documentation is updating accordingly.
>
> Seems like the binding documentation update is not part of this patch
> :)
Indeed, I forgot to do the "git commit --amend".
Thanks,
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 0/2] i2c: mv64xxx: Fix clock resource for Armada 7K/8K
From: Gregory CLEMENT @ 2018-01-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This short series fixes the way the clocks are used for the mv64xxx
controller embedded in the Marvell Armada 7K/8K SoCs. On these SoCs a
second one is needed in order to clock the registers. It was not
noticed until now because we relied on the bootloader and also because
the clock driver was wrong.
Thanks to this fix, it would be possible to fix the clock driver
without introducing a regression.
The first patch is just a small cleanup found when I wrote the main
patch.
Thanks,
Gregory
Changelog:
v1 -> v2:
- Really add the binding documentation in the second patch, noticed
by Thomas Petazzoni.
Gregory CLEMENT (2):
i2c: mv64xxx: Remove useless test before clk_disable_unprepare
i2c: mv64xxx: Fix clock resource by adding an optional bus clock
.../devicetree/bindings/i2c/i2c-mv64xxx.txt | 20 ++++++++++++++++++++
drivers/i2c/busses/i2c-mv64xxx.c | 20 +++++++++++++-------
2 files changed, 33 insertions(+), 7 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v2 1/2] i2c: mv64xxx: Remove useless test before clk_disable_unprepare
From: Gregory CLEMENT @ 2018-01-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110170743.27082-1-gregory.clement@free-electrons.com>
The 2 functions called from clk_disable_unprepare() already check that
the clock pointer is valid: no need to test it before calling it.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index a832c45276a4..f69066266faa 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -950,9 +950,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return rc;
}
@@ -965,9 +963,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return 0;
}
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110170743.27082-1-gregory.clement@free-electrons.com>
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.
The binding documentation is updating accordingly.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/i2c/i2c-mv64xxx.txt | 20 ++++++++++++++++++++
drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index 5c30026921ae..a835b724c738 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -25,6 +25,15 @@ default frequency is 100kHz
whenever you're using the "allwinner,sun6i-a31-i2c"
compatible.
+ - clocks: : pointers to the reference clocks for this device, the first
+ one is the one used for the clock on the i2c bus, the second
+ one is the clock used for the functional part of the
+ controller
+
+ - clock-names : names of used clocks, mandatory if the second clock is
+ : used, the name must be "core", and "axi_clk" (the latter is
+ only for Armada 7K/8K).
+
Examples:
i2c at 11000 {
@@ -42,3 +51,14 @@ For the Armada XP:
interrupts = <29>;
clock-frequency = <100000>;
};
+
+For the Armada 7040:
+
+ i2c at 701000 {
+ compatible = "marvell,mv78230-i2c";
+ reg = <0x701000 0x20>;
+ interrupts = <29>;
+ clock-frequency = <100000>;
+ clock-names = "core", "axi";
+ clocks = <&core_clock>, <&axi_clock>;
+ };
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index f69066266faa..cce37d8ecf41 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -135,6 +135,7 @@ struct mv64xxx_i2c_data {
u32 freq_m;
u32 freq_n;
struct clk *clk;
+ struct clk *axi_clk;
wait_queue_head_t waitq;
spinlock_t lock;
struct i2c_msg *msg;
@@ -894,13 +895,20 @@ mv64xxx_i2c_probe(struct platform_device *pd)
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
- /* Not all platforms have a clk */
+ /* Not all platforms have clocks */
drv_data->clk = devm_clk_get(&pd->dev, NULL);
if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR(drv_data->clk))
clk_prepare_enable(drv_data->clk);
+ drv_data->axi_clk = devm_clk_get(&pd->dev, "axi");
+ if (IS_ERR(drv_data->axi_clk) &&
+ PTR_ERR(drv_data->axi_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!IS_ERR(drv_data->axi_clk))
+ clk_prepare_enable(drv_data->axi_clk);
+
drv_data->irq = platform_get_irq(pd, 0);
if (pdata) {
@@ -950,6 +958,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return rc;
@@ -963,6 +972,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return 0;
--
2.15.1
^ permalink raw reply related
* [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32
From: Robin Murphy @ 2018-01-10 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155546.GB18903@lst.de>
On 10/01/18 15:55, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote:
>> On Wed, Jan 10, 2018 at 12:58:14PM +0000, Robin Murphy wrote:
>>> On 10/01/18 08:09, Christoph Hellwig wrote:
>>>> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
>>>> name the zone for that ZONE_DMA32, which will allow to use the
>>>> dma-direct and generic swiotlb code as-is, so rename it.
>>>
>>> I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32 somehow when
>>> !ZONE_DMA - there are almost certainly arm64 drivers out there using a
>>> combination of GFP_DMA and streaming mappings which will no longer get the
>>> guaranteed 32-bit addresses they expect after this. I'm not sure quite how
>>> feasible that is, though :/
>>
>> I can't find anything obvious in the tree. The alternative would be
>> to keep ZONE_DMA and set ARCH_ZONE_DMA_BITS.
>>
>>> That said, I do agree that this is an appropriate change (the legacy of
>>> GFP_DMA is obviously horrible), so, provided we get plenty of time to find
>>> and fix the fallout when it lands:
>>>
>>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>>
>> I was hoping to get this into 4.15. What would be proper time to
>> fix the fallout?
>
> Err, 4.16 of course.
Hee hee - cramming it into 4.15 is exactly what I wouldn't want to do,
even if Linus would accept it :)
Landing it this merge window for 4.16-rc1 sounds good if we can manage that.
Robin.
^ permalink raw reply
* [PATCH v2 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Thomas Petazzoni @ 2018-01-10 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110170743.27082-3-gregory.clement@free-electrons.com>
Hello,
On Wed, 10 Jan 2018 18:07:43 +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
>
> The binding documentation is updating accordingly.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> .../devicetree/bindings/i2c/i2c-mv64xxx.txt | 20 ++++++++++++++++++++
> drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
> 2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> index 5c30026921ae..a835b724c738 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> @@ -25,6 +25,15 @@ default frequency is 100kHz
> whenever you're using the "allwinner,sun6i-a31-i2c"
> compatible.
>
> + - clocks: : pointers to the reference clocks for this device, the first
> + one is the one used for the clock on the i2c bus, the second
> + one is the clock used for the functional part of the
> + controller
> +
> + - clock-names : names of used clocks, mandatory if the second clock is
> + : used, the name must be "core", and "axi_clk" (the latter is
Spurious ":" at beginning of line. In addition, the name is "axi" not
"axi_clk", at least according to your code.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 0/6] ARM branch predictor hardening
From: Marc Zyngier @ 2018-01-10 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e1e34e2-f28f-0a8b-d2c0-f65f7858dac2@ti.com>
On 10/01/18 16:50, Nishanth Menon wrote:
> On 01/08/2018 12:55 PM, Marc Zyngier wrote:
>> This small series implements some basic BP hardening by invalidating
>> the BTB on CPUs that are known to be susceptible to aliasing attacks.
>>
>> These patches are closely modelled against what we do on arm64,
>> although simpler as we can rely on an architected instruction to
>> perform the invalidation. The notable exception is Cortex-A15, where
>> BTB invalidation behaves like a NOP, and the only way to shoot the
>> predictor down is to invalidate the icache *and* to have ACTLR[0] set
>> to 1 (which is a secure-only operation).
>>
>
>
> btw, just wanted to understand if we had any reasons as to why
> we'arent tagging these for stable? Yes, I am aware of Greg's comments
> in [1], but the v7 series impacts a heck of a lot of existing products
> and is not that extensive to cause too much of a pain is it?
>
> OR, am I missing some thing else?
>
> [1] http://www.kroah.com/log/blog/2018/01/06/meltdown-status/
This is a work in progress. It is not ready for being merged yet. It can
be backported to stable after being merged into mainline.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 0/7] ARM: dts: STi: Fix DT dtc warnings
From: Patrice CHOTARD @ 2018-01-10 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2qgyJ8Hgr6fLnn6jVRhHVtcc1kxzyD2N7Bb7gzPe1xfg@mail.gmail.com>
Hi Arnd
On 01/10/2018 04:52 PM, Arnd Bergmann wrote:
> On Wed, Jan 10, 2018 at 9:21 AM, <patrice.chotard@st.com> wrote:
>> From: Patrice Chotard <patrice.chotard@st.com>
>>
>> This series fixes all dtc warnings related to STi platforms dt files.
>> It has been triggered by Rob Herring [1]
>>
>> [1] https://www.spinics.net/lists/devicetree/msg206209.html
>>
>> For most of implicated node, a simple move outside the soc node
>> solves the warnings.
>>
>> Patrice Chotard (7):
>> ARM: dts: STi: fix bindings notation
>> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property
>> ARM: dts: STi: Move clocks without reg outside soc
>> ARM: dts: STi: Move leds node outside soc node
>> ARM: dts: STi: Move usb2_picophyX nodes without reg out of soc
>> ARM: dts: STi: Move sound related nodes without reg out of soc
>> ARM: dts: STi: Add fake reg property for sti-display-subsystem
>
> Thanks a lot for addressing these!
>
> As far as I can tell, there is one patch in particular that addresses a warning
> we get at the default warning level: "ARM: dts: STi: Add gpio polarity for
> "hdmi,hpd-gpio" property". Should we merge that one for 4.15 to get closer
> to a clean build again? I'm not sure whether we can address the other
How do you want to proceed with this particular patch ?
Do you want me to send a pull-request with this patch ?
Patrice
> dtc warnings, but we're getting fairly close now.
>
> Arnd
>
^ permalink raw reply
* [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops
From: Robin Murphy @ 2018-01-10 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110153517.GF17790@lst.de>
On 10/01/18 15:35, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:16:15PM +0000, Robin Murphy wrote:
>> On 10/01/18 08:09, Christoph Hellwig wrote:
>>> To properly reject too small DMA masks based on the addressability of the
>>> bounce buffer.
>>
>> I reckon this is self-evident enough that it should simply be squashed into
>> the previous patch.
>
> x86 didn't wire it up before, so I want a clear blaimpoint for this
> change instead of mixing it up.
That almost makes sense, if x86 were using this generic swiotlb_dma_ops
already. AFAICS it's only ia64, unicore and tile who end up using it,
and they all had swiotlb_dma_supported hooked up to begin with. Am I
missing something?
If regressions are going to happen, they'll surely point at whichever
commit pulls the ops into the relevant arch code - there doesn't seem to
be a great deal of value in having a piecemeal history of said ops
*before* that point.
Robin.
^ permalink raw reply
* [PATCH 1/7] ARM: imx: add timer stop flag to ARM power off state
From: Lucas Stach @ 2018-01-10 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102164223.15230-1-stefan@agner.ch>
Am Dienstag, den 02.01.2018, 17:42 +0100 schrieb Stefan Agner:
> When the CPU is in ARM power off state the ARM architected
> timers are stopped. The flag is already present in the higher
> power WAIT mode.
>
> This allows to use the ARM generic timer on i.MX 6UL/6ULL SoC.
> Without the flag the kernel freezes when the timer enters the
> first time ARM power off mode.
>
> Cc: Anson Huang <anson.huang@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?arch/arm/mach-imx/cpuidle-imx6sx.c | 1 +
> ?1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-
> imx/cpuidle-imx6sx.c
> index c5a5c3a70ab1..d0f14b761ff7 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sx.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
> @@ -89,6 +89,7 @@ static struct cpuidle_driver imx6sx_cpuidle_driver
> = {
> ? ?*/
> ? .exit_latency = 300,
> ? .target_residency = 500,
> + .flags = CPUIDLE_FLAG_TIMER_STOP,
> ? .enter = imx6sx_enter_wait,
> ? .name = "LOW-POWER-IDLE",
> ? .desc = "ARM power off",
^ permalink raw reply
* [PATCH v2 1/6] arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17
From: Tony Lindgren @ 2018-01-10 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108185533.9698-2-marc.zyngier@arm.com>
* Marc Zyngier <marc.zyngier@arm.com> [180108 19:00]:
> In order to avoid aliasing attacks against the branch predictor,
> some implementations require to invalidate the BTB when switching
> from one user context to another.
>
> For this, we reuse the existing implementation for Cortex-A8, and
> apply it to A9, A12 and A17.
I suspect we now must also make sure Cortex-A8 has the IBE bit
set unconditionally for this to work. Currently the assumption is
that IBE bit needs to be set only on the earlier CPU revisions
that suffer from ARM_ERRATA_430973.
> --- a/arch/arm/mm/proc-v7-2level.S
> +++ b/arch/arm/mm/proc-v7-2level.S
> @@ -41,7 +41,7 @@
> * even on Cortex-A8 revisions not affected by 430973.
> * If IBE is not set, the flush BTAC/BTB won't do anything.
> */
> -ENTRY(cpu_ca8_switch_mm)
> +ENTRY(cpu_v7_btbinv_switch_mm)
> #ifdef CONFIG_MMU
> mov r2, #0
> mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB
So without IBE set, as the comments above say, the flush won't
do anything.
Regards,
Tony
^ 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