* [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
* [PATCH v2 1/6] arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17
From: Marc Zyngier @ 2018-01-10 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110175322.GZ3875@atomide.com>
On 10/01/18 17:53, Tony Lindgren wrote:
> * 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.
Indeed. Firmware/bootloaders must be updated to set IBE, just like on
Cortex-A15. I'll add a note to that effect.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Andy Shevchenko @ 2018-01-10 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110163733.GH21040@codeaurora.org>
On Wed, 2018-01-10 at 08:37 -0800, Stephen Boyd wrote:
> On 01/10, Linus Walleij wrote:
> > On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org>
> > wrote:
> for the qcom driver it was all fine
> because all three concepts: irq, gpios, and pins have a one to
> one relationship.
Just a side note: While it might be the case for most of the
controllers, don't assume it's a generic case.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH V5 00/13] drivers: Boot Constraint core
From: Rob Herring @ 2018-01-10 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110084242.GB3626@vireshk-i7>
On Wed, Jan 10, 2018 at 2:42 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-01-18, 09:08, Greg Kroah-Hartman wrote:
>> On Wed, Jan 10, 2018 at 09:14:40AM +0530, Viresh Kumar wrote:
>> > On 09-01-18, 19:47, Greg Kroah-Hartman wrote:
>> > > Can you resend this? As you can tell, I've been a bit busy for the past
>> > > month or so :(
>> >
>> > Sure.
>> >
>> > > Also, why is there no signed-off-by on the OF core patches?
>> >
>> > A bit confused, sorry. Are you looking for my signed-off ? They are already
>> > there.
>> >
>> > Or are you looking for Rob's (OF maintainer) signed-off ?
>>
>> Looking for Rob's, why hasn't he reviewed this yet?
I did review the whole series on version v4... The whole thing seems
pretty hacky to me. OTOH, I don't know if there's an elegant solution
to this problem. This also tries to be a general solution for what's
largely an earlycon (which is, news flash, a debug tool) and displays
for which we already address at least some of this with simplefb (not
that it is a great solution either). I've yet to hear of any other
concrete uses for this.
> He went through them for sure but never gave his Ack. I have asked him to
> provide Acks for the first 2 patches this morning, if they look fine to him.
The drivers/of/ changes on their own are innocent enough if there's a
reason (We generally want users using of_platform_populate rather than
of_platform_bus_create, so that's why it's not exported now.). It's
really all the rest that concerns me.
Rob
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Sekhar Nori @ 2018-01-10 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba7fa842-cfc5-6f6f-f9bf-09c74ab08ec2@lechnology.com>
On Wednesday 10 January 2018 08:31 AM, David Lechner wrote:
> On 01/09/2018 06:35 AM, Sekhar Nori wrote:
>> On Monday 08 January 2018 09:59 PM, David Lechner wrote:
>>> On 01/08/2018 08:00 AM, Sekhar Nori wrote:
>>>> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
>>>>> b/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
>>>>> new file mode 100644
>>>>> index 0000000..99bf5da
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
>>>>> @@ -0,0 +1,47 @@
>>>>> +Binding for TI DaVinci PLL Controllers
>>>>> +
>>>>> +The PLL provides clocks to most of the components on the SoC. In
>>>>> addition
>>>>> +to the PLL itself, this controller also contains bypasses, gates,
>>>>> dividers,
>>>>> +an multiplexers for various clock signals.
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: shall be one of:
>>>>> +??? - "ti,da850-pll0" for PLL0 on DA850/OMAP-L138/AM18XX
>>>>> +??? - "ti,da850-pll1" for PLL1 on DA850/OMAP-L138/AM18XX
>>>>
>>>> These PLLs are same IP so they should use the same compatible. You can
>>>> initialize both PLLs for DA850 based on the same compatible.
>>>>
>>>
>>> But they are not exactly the same. For example, PLL0 has 7 PLLDIV clocks
>>> while
>>> PLL1 only has 3. PLL0 has PREDIV while PLL1 does not. PLL0 has certain
>>> SYSCLKs
>>> that are fixed-ratio but PLL1 does not have any of these. There are even
>>> more
>>> differences, but these are the ones we are actually using.
>>
>> We need each element of the PLLC to be modeled individually as a clock
>> node.
>
> I gave this a good think while I have been working on this series
> and I came to the conclusion that we really don't need to do this.
> These components are all internal to the PLL IP block, so the
> compatible string is enough to tell us what we have. They only
> thing we need really in the device tree bindings are the connections
> that are external to the IP block.
>
>
>> That is, PLL should only model the multiplier, the dividers
>> including post and prediv should be modeled as divider clocks (hopefully
>> being able to use the clk-divider.c library). The sysclks can be
>> fixed-factor-clock type clocks.
>>
>> Without this flexible mechanism, we cannot (at least later) model things
>> like DIV4.5 clock which is the only clock which derives from the output
>> of PLL multiplier before the post divider is applied.
>>
>> Since with DT there are are no retakes, we need to get this right the
>> first time and modifying later will not be an option.
>>
>
> So, the full device tree binding would look something like this:
>
> +
> +??? pll0: clock-controller at 11000 {
> +??????? compatible = "ti,da850-pll0";
> +??????? reg = <0x11000 0x1000>;
> +??????? clocks = <&ref_clk>, <&pll1_sysclk 3>, <&pll1_obsclk>;
> +??????? clock-names = "oscin", pll1_sysclk3", "pll1_osbclk";
> +??????? oscin-square-wave;
> +
> +??????? pll0_sysclk: sysclk {
> +??????????? #clock-cells = <1>;
> +??????? };
> +
> +??????? pll0_auxclk: auxclk {
> +??????????? #clock-cells = <0>;
> +??????? };
> +
> +??????? pll0_div45: div4.5 {
> +??????????? #clock-cells = <0>;
> +??????? };
> +
> +??????? pll0_obsclk: obsclk {
> +??????????? #clock-cells = <0>;
> +??????????? assigned-clocks = <&pll0_sysclk 1>;
> +??????????? assigned-clock-names = "ocsrc";
> +??????? };
> +??? };
Well, I guess this will work as well. And I am probably biased towards
the style I mentioned because AM335x and other TI OMAP processors
follow that.
To make it easy to review that we have all bases covered, can you model
the all PLLC0 and PLLC1 (input and output) clocks for the next version?
>
> There are three clocks coming into the IP block and there are 11 clocks
> going out (sysclk is 7 clocks). And you can specify the board-specific
> configuration, like having the "oscin-square-wave" flag when a square wave
> is used instead of a crystal oscillator and you can assign the multiplexer
Ideally the OSCIN vs CLKIN selection should be another clock mux whose
output is one of the input clocks to PLL controller. But I can see the
difficulty in handling that as the mux itself is controlled by the PLL
controller.
> input that will be used by obsclk. (And, this binding is totally compatible
> with the binding I have already proposed - although, I see now it would
> be better to go ahead and add the clocks-names property.)
Also, please add the oscin-square-wave to the binding definition too.
For the benefit of others reviewing and not familiar with the hardware,
the users guide for DA850 is here:
http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf
and the PLL block diagram is on page 143 (Figure 8-1).
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V5 00/13] drivers: Boot Constraint core
From: Olof Johansson @ 2018-01-10 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513264961.git.viresh.kumar@linaro.org>
Hi,
On Thu, Dec 14, 2017 at 7:33 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Hi Greg,
>
> Here is V5 of the boot constraints core based on your feedback from V4.
> Hope this looks better now :)
>
> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX
> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm
> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C
> (This required some more patches related to display driver which
> Rajendra should be sending separately later on).
>
>
> Problem statement:
>
> Some devices are powered ON by the bootloader before the bootloader
> handovers control to Linux. It maybe important for those devices to keep
> working until the time a Linux device driver probes the device and
> reconfigure its resources.
>
> A typical example of that can be the LCD controller, which is used by
> the bootloaders to show image(s) while the platform is booting into
> Linux. The LCD controller can be using some resources, like clk,
> regulators, etc, that are shared between several devices. These shared
> resources should be configured to satisfy need of all the users. If
> another device's (X) driver gets probed before the LCD controller driver
> in this case, then it may end up disabling or reconfiguring these
> resources to ranges satisfying the current users (only device X) and
> that can make the LCD screen unstable.
>
> Another case can be a debug serial port enabled from the bootloader.
>
> Of course we can have more complex cases where the same resource is
> getting used by two devices while the kernel boots and the order in
> which devices get probed wouldn't matter as the other device will surely
> break then.
>
> There are also cases where the resources may not be shared, but the
> kernel will disable them forcefully as no users may have appeared until
> a certain point in kernel boot. This makes sure that the resources stay
> enabled. A wide variety of constraints can be satisfied using the new
> framework.
>
> Proposed solution:
>
> This series introduces the concept of "boot-constraint", which are set
> by platform specific drivers (for now at least) at early init (like
> subsys_initcall) and the kernel will keep satisfying them until the time
> driver for such a device is probed (successfully or unsuccessfully).
> Once the driver is probed, the driver core removes the constraints set
> for the device. This series implements clk, regulator and PM domain
> constraints currently.
>
> Targeted for: v4.16
>
> Pushed here:
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git boot-constraints
>
> V4->V5:
> - SPDX Licence format used.
> - arm,primecell stuff removed from boot constraint core and added a
> helper in OF core (which already handles amba and platform devices).
> - Removed a bunch of BUG_ON(), pr_fmt(), comments.
> - Changed directory and other names from
> boot_constraints/boot_constraint.
> - Removed serial.o file and moved the code to hikey and imx files.
> - Don't return error from dummy helper.
> - Added documentation and corresponding kernel doc comments in the code.
> - Updated MAINTAINERS.
>
> V3->V4:
> - Added support for imx, hikey and Qcom usecases.
> - Enhanced boot constraints core to make drivers code easy and handle
> complex cases.
> - Two new patches for OF included to provide APIs to boot constraint
> core.
> - Removed the kernel parameter patch for now.
> - Don't check return values of debugfs routines.
> - Moved the boot constraints core from drivers/base/ to drivers/.
>
> V2->V3:
> - Removed DT support as we aren't sure about how to define the bindings
> yet.
> - Added CLK and PM domain constraint types.
> - A new directory is added for boot constraints, which will also contain
> platform specific drivers in future.
> - Deferred devices are still supported, just that it wouldn't be called
> from generic code anymore but platform specific code.
> - Tested on Qcom 410c dragonboard with display flash screen (Rajendra).
> - Usual renaming/commit-log-updates/etc changes done.
>
> V1->V2:
> - Add support for setting constraints for devices created from DT.
> - Allow handling deferred devices earlier then late_init.
> - Remove 'default y' line from kconfig.
> - Drop '=" after boot_constraints_disable kernel param.
> - Dropped the dummy testing patch now.
>
> --
> viresh
>
> Rajendra Nayak (1):
> boot_constraint: Add Qualcomm display controller constraints
>
> Viresh Kumar (12):
> of: platform: Add of_find_any_device_by_node()
> of: platform: Make of_platform_bus_create() global
> drivers: Add boot constraints core
> boot_constraint: Add support for supply constraints
> boot_constraint: Add support for clk constraints
> boot_constraint: Add support for PM constraints
> boot_constraint: Add debugfs support
> boot_constraint: Manage deferrable constraints
> boot_constraint: Add support for Hisilicon platforms
> boot_constraint: Add support for IMX platform
> boot_constraint: Update MAINTAINERS
> boot_constraint: Add documentation
>
> .../driver-api/boot-constraint/constraints.rst | 98 +++++++
> Documentation/driver-api/boot-constraint/index.rst | 4 +
> Documentation/driver-api/index.rst | 1 +
> MAINTAINERS | 9 +
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm64/Kconfig.platforms | 2 +
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/base/dd.c | 32 ++-
> drivers/boot_constraint/Kconfig | 9 +
> drivers/boot_constraint/Makefile | 7 +
> drivers/boot_constraint/clk.c | 70 +++++
> drivers/boot_constraint/core.c | 290 +++++++++++++++++++++
> drivers/boot_constraint/core.h | 47 ++++
> drivers/boot_constraint/deferrable_dev.c | 241 +++++++++++++++++
> drivers/boot_constraint/hikey.c | 158 +++++++++++
> drivers/boot_constraint/imx.c | 126 +++++++++
> drivers/boot_constraint/pm.c | 28 ++
> drivers/boot_constraint/qcom.c | 122 +++++++++
> drivers/boot_constraint/supply.c | 104 ++++++++
The SoC-specific pieces should preferrably go under drivers/soc
instead, to reduce cross-tree dependencies when introducing new SoC
variants.
They're more related to the SoC than to the boot_constraint framework anyway.
Bikeshed: We've traditionally had really terse and precise names under
drivers/. This is the first verbose one with a _ in it. Maybe find a
shorter name or just concatenate to 'bootconstraints'? We didn't call
it remote_proc or rapid_io, etc, either. :)
-Olof
^ permalink raw reply
* [RFC 0/4] KVM: Support PUD hugepages at stage 2
From: Punit Agrawal @ 2018-01-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patchset adds support for PUD hugepages at stage 2. This feature
is useful on cores that have support for large sized TLB mappings
(e.g., 1GB for 4K granule).
The patchset is based on v4.15-rc7 and depends on a fix sent out
earlier[0]. There patchset will conflict with Suzuki's work to
dynamically set IPA size. I'll work with Suzuki to resolve this
depending on the order the features are merged.
The patches have been functionally tested on an A57 based system. To
quantify the benefit, the patches need to be evaluated on cores
supporting larger sized TLB mappings.
I'm sending the patchset as RFC to get feedback on the code as well as
allow evaluation on real systems.
Thanks,
Punit
[0] https://patchwork.kernel.org/patch/10145339/
Punit Agrawal (4):
arm64: Correct type for PUD macros
KVM: arm64: Support dirty page tracking for PUD hugepages
KVM: arm/arm64: Refactor Stage2 PMD hugepages support
KVM: arm64: Add support for PUD hugepages at stage 2
arch/arm/include/asm/kvm_mmu.h | 19 +++++++
arch/arm/include/asm/pgtable-3level.h | 2 +
arch/arm64/include/asm/kvm_mmu.h | 29 +++++++++++
arch/arm64/include/asm/pgtable-hwdef.h | 8 +--
arch/arm64/include/asm/pgtable.h | 4 ++
virt/kvm/arm/mmu.c | 91 +++++++++++++++++++++++++++++-----
6 files changed, 137 insertions(+), 16 deletions(-)
--
2.15.1
^ permalink raw reply
* [RFC 1/4] arm64: Correct type for PUD macros
From: Punit Agrawal @ 2018-01-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110190729.18383-1-punit.agrawal@arm.com>
The PUD macros (PUD_TABLE_BIT, PUD_TYPE_MASK, PUD_TYPE_SECT) use the
pgdval_t even when pudval_t is available. Even though the underlying
type for both (u64) is the same it is confusing and may lead to issues
in the future.
Fix this by using pudval_t to define the PUD_* macros.
Fixes: 084bd29810a56 ("ARM64: mm: HugeTLB support.")
Fixes: 206a2a73a62d3 ("arm64: mm: Create gigabyte kernel logical mappings where possible")
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/pgtable-hwdef.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
index eb0c2bd90de9..40a998cdd399 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -116,9 +116,9 @@
* Level 1 descriptor (PUD).
*/
#define PUD_TYPE_TABLE (_AT(pudval_t, 3) << 0)
-#define PUD_TABLE_BIT (_AT(pgdval_t, 1) << 1)
-#define PUD_TYPE_MASK (_AT(pgdval_t, 3) << 0)
-#define PUD_TYPE_SECT (_AT(pgdval_t, 1) << 0)
+#define PUD_TABLE_BIT (_AT(pudval_t, 1) << 1)
+#define PUD_TYPE_MASK (_AT(pudval_t, 3) << 0)
+#define PUD_TYPE_SECT (_AT(pudval_t, 1) << 0)
/*
* Level 2 descriptor (PMD).
--
2.15.1
^ permalink raw reply related
* [RFC 2/4] KVM: arm64: Support dirty page tracking for PUD hugepages
From: Punit Agrawal @ 2018-01-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110190729.18383-1-punit.agrawal@arm.com>
In preparation for creating PUD hugepages at stage 2, add support for
write protecting PUD hugepages when they are encountered. Write
protecting guest tables is used to track dirty pages when migrating VMs.
Also, provide trivial implementations of required kvm_s2pud_* helpers to
allow code to compile on arm32.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_mmu.h | 9 +++++++++
arch/arm64/include/asm/kvm_mmu.h | 10 ++++++++++
virt/kvm/arm/mmu.c | 9 ++++++---
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index fa6f2174276b..3fbe919b9181 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -103,6 +103,15 @@ static inline bool kvm_s2pmd_readonly(pmd_t *pmd)
return (pmd_val(*pmd) & L_PMD_S2_RDWR) == L_PMD_S2_RDONLY;
}
+static inline void kvm_set_s2pud_readonly(pud_t *pud)
+{
+}
+
+static inline bool kvm_s2pud_readonly(pud_t *pud)
+{
+ return true;
+}
+
static inline bool kvm_page_empty(void *ptr)
{
struct page *ptr_page = virt_to_page(ptr);
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 672c8684d5c2..dbfd18e08cfb 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -201,6 +201,16 @@ static inline bool kvm_s2pmd_readonly(pmd_t *pmd)
return kvm_s2pte_readonly((pte_t *)pmd);
}
+static inline void kvm_set_s2pud_readonly(pud_t *pud)
+{
+ kvm_set_s2pte_readonly((pte_t *)pud);
+}
+
+static inline bool kvm_s2pud_readonly(pud_t *pud)
+{
+ return kvm_s2pte_readonly((pte_t *)pud);
+}
+
static inline bool kvm_page_empty(void *ptr)
{
struct page *ptr_page = virt_to_page(ptr);
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 9dea96380339..02eefda5d71e 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1155,9 +1155,12 @@ static void stage2_wp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
do {
next = stage2_pud_addr_end(addr, end);
if (!stage2_pud_none(*pud)) {
- /* TODO:PUD not supported, revisit later if supported */
- BUG_ON(stage2_pud_huge(*pud));
- stage2_wp_pmds(pud, addr, next);
+ if (stage2_pud_huge(*pud)) {
+ if (!kvm_s2pud_readonly(pud))
+ kvm_set_s2pud_readonly(pud);
+ } else {
+ stage2_wp_pmds(pud, addr, next);
+ }
}
} while (pud++, addr = next, addr != end);
}
--
2.15.1
^ permalink raw reply related
* [RFC 3/4] KVM: arm/arm64: Refactor Stage2 PMD hugepages support
From: Punit Agrawal @ 2018-01-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110190729.18383-1-punit.agrawal@arm.com>
Refactor the stage2 PMD hugepages support to split out constructing the
PMD into a separate function. A similar pattern of code will be followed
when introducing PUD hugepages at stage 2 where we need to split support
between architecure specific and common code.
There is no functional change with this patch.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/mmu.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 02eefda5d71e..f02219a91b19 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1282,6 +1282,17 @@ static void kvm_send_hwpoison_signal(unsigned long address,
send_sig_info(SIGBUS, &info, current);
}
+static pmd_t stage2_build_pmd(kvm_pfn_t pfn, pgprot_t mem_type, bool writable)
+{
+ pmd_t pmd = pfn_pmd(pfn, mem_type);
+
+ pmd = pmd_mkhuge(pmd);
+ if (writable)
+ pmd = kvm_s2pmd_mkwrite(pmd);
+
+ return pmd;
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -1386,12 +1397,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
if (hugetlb) {
- pmd_t new_pmd = pfn_pmd(pfn, mem_type);
- new_pmd = pmd_mkhuge(new_pmd);
- if (writable) {
- new_pmd = kvm_s2pmd_mkwrite(new_pmd);
+ pmd_t new_pmd = stage2_build_pmd(pfn, mem_type, writable);
+
+ if (writable)
kvm_set_pfn_dirty(pfn);
- }
+
coherent_cache_guest_page(vcpu, pfn, PMD_SIZE);
ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, &new_pmd);
} else {
--
2.15.1
^ permalink raw reply related
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