* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Benjamin Herrenschmidt @ 2018-01-11 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109223126.13093-4-jae.hyun.yoo@linux.intel.com>
On Tue, 2018-01-09 at 14:31 -0800, Jae Hyun Yoo wrote:
> +struct peci_rd_ia_msr_msg {
> + unsigned char target;
> + unsigned char thread_id;
> + unsigned short address;
> + unsigned long value;
> +};
Those types are representing messages on the wire ?
In that case those types aren't suitable. For example "long" will have
a different size and alignment for 32 and 64-bit userspace. There are
size-explicit userspace types available.
Also I didn't see any endianness annotations in there. Is that expected
? IE are those wire format packets ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/3] ARM: dts: mvebu: add sdram controller node to Armada-38x
From: Gregory CLEMENT @ 2018-01-11 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5aa9a523e86e4607a14265790d105168@svr-chch-ex1.atlnz.lc>
Hi Chris,
On mer., janv. 10 2018, Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
> On 10/01/18 21:31, Gregory CLEMENT wrote:
>> Hi Chris,
>>
>> On mar., janv. 09 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>>
>>> The Armada-38x uses an SDRAM controller that is compatible with the
>>> Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
>>> is 32/16). The SDRAM controller registers are the same between the two
>>> SoCs.
>>>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>> ---
>>> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>>> index 00ff549d4e39..6d34c5ec178f 100644
>>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>>> @@ -138,6 +138,11 @@
>>> #size-cells = <1>;
>>> ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
>>>
>>> + sdramc at 1400 {
>>
>> Could you add a label? Thanks to this it would be possible to
>> enable/disable it at board level in a esay way.
>>
>
> Sure. Any suggestions for a name better than "sdramc:"?
For me sdramc: is fine.
>
> It's probably worth adding the same label to armada-xp.dtsi and
> armada-xp-98dx3236.dtsi.
Right.
>
>>> + compatible = "marvell,armada-xp-sdram-controller";
>>> + reg = <0x1400 0x500>;
>>
>> What about adding status = "disabled" ?
>>
>> Thanks to this we can enable it at board level only if we really want
>> it, it would avoid nasty regression on boards that don't need it, if an
>> issue occurs. Unless you are sure that it is completely safe to enable
>> it for everyone.
>
> The EDAC driver (which is default n) will not probe the device if ECC
> has not been enabled so that should be safe.
OK in this case no need to disable it by default.
Thanks,
Gregory
>
> Other than the EDAC driver the only other code that looks at this is in
> arch/arm/mach-mvebu/pm.c and it almost seems like an omission that this
> code is not active on armada-38x. The armada-38x platforms I have access
> to don't use suspend/resume so I can't verify this.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM64: dts: meson-axg: add RMII pins for ethernet controller
From: Yixun Lan @ 2018-01-11 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515659863.5048.112.camel@baylibre.com>
Hi Jerome?
On 01/11/18 16:37, Jerome Brunet wrote:
> On Thu, 2018-01-11 at 11:04 +0800, Yixun Lan wrote:
>> Comparing to RGMII interface, the RMII interface require few pins.
>> So it's worth describing them here.
>>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> The only axg platform we have upstream is the s400 and is using rgmii.
> May I ask how this was tested ?
>
It's true that S400 using RGMII interface.
but, we have customer using RTL8201FR-VB/VD which is a RMII PHY,
This is actually tested with the 'eth_rmii_x_pins' group.
Yixun
^ permalink raw reply
* [PATCH v2 0/3] ARM: mvebu: dts: updates to enable EDAC
From: Gregory CLEMENT @ 2018-01-11 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111015903.11322-1-chris.packham@alliedtelesis.co.nz>
Hi Chris,
On jeu., janv. 11 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> I've split this off from my earlier series[1] this is just the dts changes that
> will enable support for the EDAC series when it lands.
>
> The Armada 38x as well as the 98dx3236 and similar switch chips with integrated
> CPUs use the same SDRAM controller block as the Armada XP. The key difference
> is the width of the DDR interface.
>
> [1] - https://marc.info/?l=linux-kernel&m=151545124505964&w=2
The series is looks good now. For patch 1 I still wait for that
the "marvell,,ecc-enable" property was accepted before merging it.
So I can either wait for that it was accepted before applying the series,
or just applying patch 2 and 3 for now, as you want.
Thanks,
Gregory
>
> Changes in v2:
> - update commit message
> - add labels to dts
>
> Chris Packham (3):
> ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
> ARM: dts: armada-xp: add label to sdram-controller node
> ARM: dts: mvebu: add sdram controller node to Armada-38x
>
> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
> arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> --
> 2.15.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Arnd Bergmann @ 2018-01-11 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111084128.GA16780@kroah.com>
On Thu, Jan 11, 2018 at 9:41 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote:
>> On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote:
>> >> Thanks for your pointing it out and I totally agree with you. Actually, we
>> >> are preparing 4.13 update for now and an another update will be followed up.
>> >> As I answered above, I'll rebase this patch set onto the latest kernel.org
>> >> mainline. Sorry for my misunderstanding of upstream process.
>> >
>> > 4.13? Why that kernel? It too is obsolete and insecure and
>> > unsupported.
>>
>> It contains support for our hardware that I have integrated from work
>> in progress patches and upstream commits.
>>
>> The OpenBMC project, with myself as the kernel maintainer, have
>> intentions to regularly move to upstream releases. This takes time and
>> effort. This time and effort is balanced with submitting our drivers
>> upstream.
>
> Of course, but please do not have your "users" use a kernel that is
> known to have bugs and can not be supported. That would not be good at
> all, don't you think?
I've been pretty happy with the progress in merging drivers upstream
for OpenBMC. Of course things always take longer than planned,
but they are getting there. Most servers today are probably running
the aspeed vendor kernel based on linux-2.6.28.10, at least that's
what my workstation runs (and no, I did not connect the BMC to my
home network).
The particular choices of mainline versions (4.10 and 4.13) may be
unfortunate as they are both one off from a longterm release, but
not being stuck on 2.6 is the important first step in order to upstream
stuff.
>> Another silicon vendor has recently joined the project and that brings
>> an entire SoC that is not upstream. We have patches on the ARM that
>> are under review for this SoC, with more drivers undergoing cleanup in
>> order to submit them to the relevant maintainers.
>
> Why are you merging all SoC trees together into one place? That seems
> like a nightmare to manage, especially with git.
Why would anyone want to have multiple kernel trees just to run
things on different SoCs? ;-)
It's just a collection of device drivers in different stages of getting
upstreamed.
>> > And if you do have out-of-tree code, why not use a process that makes it
>> > trivial to update the base kernel version so that you can keep up to
>> > date very easily? (hint, just using 'git' is not a good way to do
>> > this...)
>>
>> We have a process that we've been developing under for the past few
>> years. I find git to be a great tool for managing Linux kernel trees.
>>
>> What would you recommend for managing kernel trees?
>
> quilt is best for a tree that you can not rebase (i.e. a public git
> tree). Otherwise you end up getting patches all mushed together and
> hard to extract in any simple way.
I'm ususally happy with having git with topic branches to make the
rebasing easier. In many cases, you can just leave a topic branch
for a particular subsystem unchanged between versions and just
merge the latest version of those branches until the branch goes
away after upstreaming.
Arnd
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Benjamin Herrenschmidt @ 2018-01-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111084128.GA16780@kroah.com>
On Thu, 2018-01-11 at 09:41 +0100, Greg KH wrote:
> On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote:
> > On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote:
> > > > Thanks for your pointing it out and I totally agree with you. Actually, we
> > > > are preparing 4.13 update for now and an another update will be followed up.
> > > > As I answered above, I'll rebase this patch set onto the latest kernel.org
> > > > mainline. Sorry for my misunderstanding of upstream process.
> > >
> > > 4.13? Why that kernel? It too is obsolete and insecure and
> > > unsupported.
> >
> > It contains support for our hardware that I have integrated from work
> > in progress patches and upstream commits.
> >
> > The OpenBMC project, with myself as the kernel maintainer, have
> > intentions to regularly move to upstream releases. This takes time and
> > effort. This time and effort is balanced with submitting our drivers
> > upstream.
>
> Of course, but please do not have your "users" use a kernel that is
> known to have bugs and can not be supported. That would not be good at
> all, don't you think?
There is little choice, we don't have the manpower to rewrite/upstream
all the drivers in a day, and rebasing to newer kernel takes time due
to various dependencies, testing requirements etc.
That being said, 4.13 is N-1, not too bad.
> > > What keeps you all from just always tracking the latest tree from Linus?
> >
> > Linus' tree does not contain all of the drivers required to boot
> > systems. Many of them are still under review on lkml, and others still
> > require rewrite from the vendor tree.
>
> Merging vendor trees into your tree has got to be a complicated mess.
> Why try to keep it all together in one place?
There are no vendor trees to speak of that we could merge. At least not
yet. We've been teaching vendors about doing proper drivers that can
work with upstream, device-tree based platforms etc... but it takes
time for them to get up to speed.
So while we are rewriting the drivers (sometimes with the vendor's
help), we keep a tree with the "sub-standard" ones hacked up to work on
our DT based platform and with our other bits and pieces until we can
ditch it.
> And who is responsible for getting the vendor code upstream? The
> individual drivers? Individual driver submissions should be quite easy,
> what is preventing them from getting merged?
It just takes time Greg. The original vendor drivers are in no shape to
get anywhere near upstream. They have to be mostly rewritten one by
one. Sometimes we can teach the vendor and help them along, some times
we do it ourselves, but it's a time consuming process. It took 2 or 3
kernel versions just to get the clk drivers that Joel had written
upstream for example. It took me a long time as well to get ftgmac100
sorted.
> > > What is in your tree that is not upstream that requires you to have a
> > > kernel tree at all?
> >
> > We have PECI, video compression, crypto, USB CDC, DRM (graphics),
> > serial GPIO, LPC mailbox for the ASPEED SoC.
>
> What "USB CDC" do you have that is not upstream?
See my other email :)
> I'll pick on this one
> specifically as I don't think I've seen any patches recently submitted
> for that driver at all. Am I just missing them?
>
> The other ones should also all be easy to get merged, with maybe the
> exception of the drm stuff due to the speed that subsystem moves at.
> But even there, the community is very helpful in getting stuff upstream,
> have you asked for help?
We can't expect the community to rewrite the drivers for us. Some of
the clk and pinmux stuff is intrinsically very complex, and took time
(and we did get valuable feedback).
Now that these basic pieces of infrastructure are in, it's a matter of
tackling the remaining drivers one at a time.
> > Another silicon vendor has recently joined the project and that brings
> > an entire SoC that is not upstream. We have patches on the ARM that
> > are under review for this SoC, with more drivers undergoing cleanup in
> > order to submit them to the relevant maintainers.
>
> Why are you merging all SoC trees together into one place? That seems
> like a nightmare to manage, especially with git.
There are no SoC trees per-se.
There is the OpenBMC tree which has hand-hacked vendor drivers plugged
into it, which are going away one at a time as we clean them up.
There's really one SoC family only in use (aspeed) at the moment with
one other coming around the corner (Nuvoton). For the latter, my
understanding is that we are trying to get the vendor to get their
stuff upstream directly.
> > > And if you do have out-of-tree code, why not use a process that makes it
> > > trivial to update the base kernel version so that you can keep up to
> > > date very easily? (hint, just using 'git' is not a good way to do
> > > this...)
> >
> > We have a process that we've been developing under for the past few
> > years. I find git to be a great tool for managing Linux kernel trees.
> >
> > What would you recommend for managing kernel trees?
>
> quilt is best for a tree that you can not rebase (i.e. a public git
> tree). Otherwise you end up getting patches all mushed together and
> hard to extract in any simple way.
>
> Take a clue from the distros that have been managing kernels for decades
> and deal with an updated kernel all the time easily.
>
> Good luck, it sounds like you will need it :)
Nah, not luck, we just need to get those drivers done one at a time,
it's not a matter of luck.
And I find git to be just fine :)
Cheers,
Ben.
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH v2 1/5] pinctrl: imx: use struct imx_pinctrl_soc_info as a const
From: Linus Walleij @ 2018-01-11 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-2-stefan@agner.ch>
On Sat, Jan 6, 2018 at 3:25 PM, Stefan Agner <stefan@agner.ch> wrote:
> For some SoCs the struct imx_pinctrl_soc_info is passed through
> of_device_id.data which is const. Most variables are already const
> or otherwise not written. However, some fields are modified at
> runtime. Move those fields to the dynamically allocated struct
> imx_pinctrl.
>
> Fixes: b3060044e495 ("pinctrl: freescale: imx7d: make of_device_ids const")
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/5] pinctrl: imx7d: simplify imx7d_pinctrl_probe
From: Linus Walleij @ 2018-01-11 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-3-stefan@agner.ch>
On Sat, Jan 6, 2018 at 3:25 PM, Stefan Agner <stefan@agner.ch> wrote:
> Using of_device_get_match_data in imx7d_pinctrl_probe simplifies
> the function. Also get rid of the void pointer cast since
> imx_pinctrl_probe now accepts const struct imx_pinctrl_soc_info.
>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/5] pinctrl: imx: constify struct imx_pinctrl_soc_info
From: Linus Walleij @ 2018-01-11 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-4-stefan@agner.ch>
On Sat, Jan 6, 2018 at 3:25 PM, Stefan Agner <stefan@agner.ch> wrote:
> Now that imx_pinctrl_probe accepts const struct imx_pinctrl_soc_info
> we can constify all declarations of struct imx_pinctrl_soc_info.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 4/5] pinctrl: imx7ulp: constify struct imx_cfg_params_decode
From: Linus Walleij @ 2018-01-11 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-5-stefan@agner.ch>
On Sat, Jan 6, 2018 at 3:25 PM, Stefan Agner <stefan@agner.ch> wrote:
> The decode parameters are constant mark them const.
>
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM64: dts: meson-axg: add RMII pins for ethernet controller
From: Neil Armstrong @ 2018-01-11 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fa28259-cce9-37fc-3bcd-6017a35a052a@amlogic.com>
On 11/01/2018 10:11, Yixun Lan wrote:
> Hi Jerome?
>
> On 01/11/18 16:37, Jerome Brunet wrote:
>> On Thu, 2018-01-11 at 11:04 +0800, Yixun Lan wrote:
>>> Comparing to RGMII interface, the RMII interface require few pins.
>>> So it's worth describing them here.
>>>
>>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>>
>> The only axg platform we have upstream is the s400 and is using rgmii.
>> May I ask how this was tested ?
>>
> It's true that S400 using RGMII interface.
>
> but, we have customer using RTL8201FR-VB/VD which is a RMII PHY,
>
> This is actually tested with the 'eth_rmii_x_pins' group.
>
> Yixun
>
I pushed the same for GXBB,
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH 0/7] Initial Allwinner H6 support
From: Linus Walleij @ 2018-01-11 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106041813.46256-1-icenowy@aosc.io>
On Sat, Jan 6, 2018 at 5:18 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> This patchset adds initial support for the Allwinner H6 SoC.
Can I apply the pin control patches without the clock patches?
Also waiting for Maxime and/or Chen-Yu to provide some review
before merging this.
Yours,
Linus Walleij
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 0/7] Initial Allwinner H6 support
From: Icenowy Zheng @ 2018-01-11 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY3xY-7-YTCS=QmRQ3hmXiJZ_2M=ZhJRTTMx7XNfXRRSw@mail.gmail.com>
? 2018?1?11???? CST ??5:36:39?Linus Walleij ???
> On Sat, Jan 6, 2018 at 5:18 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > This patchset adds initial support for the Allwinner H6 SoC.
>
> Can I apply the pin control patches without the clock patches?
I think it's OK.
Note: on H6 now the pin controller do not depend on
the CCU at all -- it only needs two oscillators now.
>
> Also waiting for Maxime and/or Chen-Yu to provide some review
> before merging this.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH 3/4] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
From: Linus Walleij @ 2018-01-11 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110034557.5sqpbsvt6ly6s2go@tarshish>
On Wed, Jan 10, 2018 at 4:45 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Linus,
>
> On Wed, Jan 03, 2018 at 11:08:15AM +0100, Linus Walleij wrote:
>> On Tue, Jan 2, 2018 at 2:19 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > +#include <linux/err.h>
>> > +#include <linux/gpio.h>
>>
>> Just use
>>
>> #include <linux/driver.h>
>
> You mean linux/gpio/driver.h, right?
Yes.
> I still need linux/gpio.h for GPIOF_DIR_*.
Don't use these, just use 0 and 1 open coded for the
moment (if you check my devel branch, the references to
these flags are gone).
We need to make new defines for the new API.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/9] iommu/of: Drop early initialisation hooks
From: Marek Szyprowski @ 2018-01-11 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111082229.24011-2-jeffy.chen@rock-chips.com>
Hi Jeffy,
On 2018-01-11 09:22, Jeffy Chen wrote:
> With the probe-deferral mechanism, early initialisation hooks are no
> longer needed.
>
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> drivers/iommu/arm-smmu-v3.c | 2 +-
> drivers/iommu/arm-smmu.c | 12 ++++++------
> drivers/iommu/exynos-iommu.c | 2 +-
For Exynos IOMMU:
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
Remove custom platform device registration code") broke Exynos IOMMU.
You need a similar fix for them:
https://www.spinics.net/lists/arm-kernel/msg627648.html
> drivers/iommu/ipmmu-vmsa.c | 17 ++---------------
> drivers/iommu/msm_iommu.c | 24 +++++++-----------------
> drivers/iommu/of_iommu.c | 16 ----------------
> drivers/iommu/qcom_iommu.c | 2 +-
> include/linux/of_iommu.h | 6 ++----
> 8 files changed, 20 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 744592d330ca..3f2f1fc68b52 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2971,7 +2971,7 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", NULL);
> +IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
>
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 78d4c6b8f1ba..69e7c60792a8 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,12 +2211,12 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", NULL);
> -IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", NULL);
> -IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", NULL);
> -IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", NULL);
> -IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", NULL);
> -IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", NULL);
> +IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
> +IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
> +IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
> +IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
> +IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
> +IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
>
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 79c45650f8de..1c7f926fad0e 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1394,4 +1394,4 @@ static int __init exynos_iommu_init(void)
> }
> core_initcall(exynos_iommu_init);
>
> -IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu", NULL);
> +IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 8dce3a9de9d8..07b711bb4b16 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1081,12 +1081,8 @@ static struct platform_driver ipmmu_driver = {
>
> static int __init ipmmu_init(void)
> {
> - static bool setup_done;
> int ret;
>
> - if (setup_done)
> - return 0;
> -
> ret = platform_driver_register(&ipmmu_driver);
> if (ret < 0)
> return ret;
> @@ -1096,7 +1092,6 @@ static int __init ipmmu_init(void)
> bus_set_iommu(&platform_bus_type, &ipmmu_ops);
> #endif
>
> - setup_done = true;
> return 0;
> }
>
> @@ -1109,16 +1104,8 @@ subsys_initcall(ipmmu_init);
> module_exit(ipmmu_exit);
>
> #ifdef CONFIG_IOMMU_DMA
> -static int __init ipmmu_vmsa_iommu_of_setup(struct device_node *np)
> -{
> - ipmmu_init();
> - return 0;
> -}
> -
> -IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa",
> - ipmmu_vmsa_iommu_of_setup);
> -IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
> - ipmmu_vmsa_iommu_of_setup);
> +IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
> +IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
> #endif
>
> MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 04f4d51ffacb..a41d4251b0a9 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -856,7 +856,7 @@ static struct platform_driver msm_iommu_driver = {
> .remove = msm_iommu_remove,
> };
>
> -static int __init msm_iommu_driver_init(void)
> +static int __init msm_iommu_init(void)
> {
> int ret;
>
> @@ -864,30 +864,20 @@ static int __init msm_iommu_driver_init(void)
> if (ret != 0)
> pr_err("Failed to register IOMMU driver\n");
>
> + bus_set_iommu(&platform_bus_type, &msm_iommu_ops);
> +
> return ret;
> }
>
> -static void __exit msm_iommu_driver_exit(void)
> +static void __exit msm_iommu_exit(void)
> {
> platform_driver_unregister(&msm_iommu_driver);
> }
>
> -subsys_initcall(msm_iommu_driver_init);
> -module_exit(msm_iommu_driver_exit);
> -
> -static int __init msm_iommu_init(void)
> -{
> - bus_set_iommu(&platform_bus_type, &msm_iommu_ops);
> - return 0;
> -}
> -
> -static int __init msm_iommu_of_setup(struct device_node *np)
> -{
> - msm_iommu_init();
> - return 0;
> -}
> +subsys_initcall(msm_iommu_init);
> +module_exit(msm_iommu_exit);
>
> -IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu", msm_iommu_of_setup);
> +IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Stepan Moskovchenko <stepanm@codeaurora.org>");
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 50947ebb6d17..5c36a8b7656a 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -231,19 +231,3 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> return ops;
> }
> -
> -static int __init of_iommu_init(void)
> -{
> - struct device_node *np;
> - const struct of_device_id *match, *matches = &__iommu_of_table;
> -
> - for_each_matching_node_and_match(np, matches, &match) {
> - const of_iommu_init_fn init_fn = match->data;
> -
> - if (init_fn && init_fn(np))
> - pr_err("Failed to initialise IOMMU %pOF\n", np);
> - }
> -
> - return 0;
> -}
> -postcore_initcall_sync(of_iommu_init);
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index e07f02d00c68..65b9c99707f8 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -947,7 +947,7 @@ static void __exit qcom_iommu_exit(void)
> module_init(qcom_iommu_init);
> module_exit(qcom_iommu_exit);
>
> -IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1", NULL);
> +IOMMU_OF_DECLARE(qcom_iommu_dev, "qcom,msm-iommu-v1");
>
> MODULE_DESCRIPTION("IOMMU API for QCOM IOMMU v1 implementations");
> MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index cddfaff4d0b7..ae03752e8e3a 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -34,9 +34,7 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> extern struct of_device_id __iommu_of_table;
>
> -typedef int (*of_iommu_init_fn)(struct device_node *);
> -
> -#define IOMMU_OF_DECLARE(name, compat, fn) \
> - _OF_DECLARE(iommu, name, compat, fn, of_iommu_init_fn)
> +#define IOMMU_OF_DECLARE(name, compat) \
> + OF_DECLARE_1(iommu, name, compat, NULL)
>
> #endif /* __OF_IOMMU_H */
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] pinctrl: uniphier: refactor drive strength get/set functions
From: Linus Walleij @ 2018-01-11 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515573254-8894-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, Jan 10, 2018 at 9:34 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> There is code duplication between uniphier_conf_pin_drive_get() and
> uniphier_conf_pin_drive_set(). Factor out the common code into
> uniphier_conf_get_drvctrl_data().
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] pinctrl: mediatek: mt7622: fix potential uninitialized value being returned
From: Linus Walleij @ 2018-01-11 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a26c40a8ad2af3cf81b31ae34bc82c1ef80d9279.1515514758.git.sean.wang@mediatek.com>
On Tue, Jan 9, 2018 at 5:28 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> commit d6ed93551320 ("pinctrl: mediatek: add pinctrl driver for MT7622
> SoC") leads to the following static checker warning:
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] pinctrl: mediatek: mt7622: align error handling of mtk_hw_get_value call
From: Linus Walleij @ 2018-01-11 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0eb8fd904f9b49d0e992bc2ee725d057f94cf735.1515514758.git.sean.wang@mediatek.com>
On Tue, Jan 9, 2018 at 5:28 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Make consistent error handling of all mtk_hw_get_value occurrences using
> propagating error code from the internal instead of creating a new one.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Linus Walleij @ 2018-01-11 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
On Mon, Jan 8, 2018 at 8:33 AM, Yixun Lan <yixun.lan@amlogic.com> wrote:
> These two patches are general improvement for meson pinctrl driver.
> It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
> one hardware block even its pin groups live inside two differet hardware domains,
> which for example EE vs AO domain here.
>
> This idea is motivated by Martin's question at [1]
>
> [1]
> http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
There seems to be controversy here so I'd like input from Carlo
and/or Beniamino if possible.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V5 00/13] drivers: Boot Constraint core
From: Viresh Kumar @ 2018-01-11 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgeaWd5z7VEiVhs=Ei3ZWZQN0C-p4smTMCy3AYrZ-TdTA@mail.gmail.com>
On 10-01-18, 10:54, Olof Johansson wrote:
> 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.
Hmm, okay.
> 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. :)
Sure.
--
viresh
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Greg KH @ 2018-01-11 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515661011.31850.27.camel@au1.ibm.com>
On Thu, Jan 11, 2018 at 07:56:51PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-01-11 at 08:30 +0100, Greg KH wrote:
> > 4.13? Why that kernel? It too is obsolete and insecure and
> > unsupported.
>
> Haha, it's n-1. come on :-)
And, if you use it in a device, it's still totally unsupported and
insecure. Seriously, does no one actually pay attention to the patches
I merge in the stable trees anymore?
Anyway, your other comments are good, glad to see work is progressing
well, and yes it's better than a 2.6.y based kernel, but really, that's
a low bar...
thanks,
greg k-h
^ permalink raw reply
* [linux-sunxi] [PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate
From: Andre Przywara @ 2018-01-11 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106042326.46519-1-icenowy@aosc.io>
Hi,
On 06/01/18 04:23, Icenowy Zheng wrote:
> The Allwinner H6 pin controllers (both the main one and the CPUs one)
> have no bus gate clocks.
>
> Add support for this kind of pin controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 ++++++++++++++++++++----------
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
> 2 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 4b6cb25bc796..68cd505679d9 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -1182,7 +1182,12 @@ static int sunxi_pinctrl_setup_debounce(struct sunxi_pinctrl *pctl,
> unsigned int hosc_div, losc_div;
> struct clk *hosc, *losc;
> u8 div, src;
> - int i, ret;
> + int i, ret, clk_count;
> +
> + if (pctl->desc->without_bus_gate)
> + clk_count = 2;
> + else
> + clk_count = 3;
>
> /* Deal with old DTs that didn't have the oscillators */
> if (of_count_phandle_with_args(node, "clocks", "#clock-cells") != 3)
> @@ -1360,15 +1365,19 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
> goto gpiochip_error;
> }
>
> - clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - goto gpiochip_error;
> - }
> + if (!desc->without_bus_gate) {
Do we really need explicit support for that case?
Can't we have something that works automatically?
if (node has clock-names property) (A)
use clocks as enumerated and named there
else if (node has one clock reference) (B)
use this as gate clock, no debounce support
else if (node has no clock property at all) (C)
no gate clock needed, no debounce support
On top of that we should add the clock-names property to all DTs, even
for those with only a "apb" clock. Shouldn't hurt existing kernels.
Possibly even add debounce support for those on the way, if applicable.
So we would just support case (B) and (C) for legacy reasons.
Does that make sense?
Cheers,
Andre.
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + goto gpiochip_error;
> + }
>
> - ret = clk_prepare_enable(clk);
> - if (ret)
> - goto gpiochip_error;
> + ret = clk_prepare_enable(clk);
> + if (ret)
> + goto gpiochip_error;
> + } else {
> + clk = NULL;
> + }
>
> pctl->irq = devm_kcalloc(&pdev->dev,
> pctl->desc->irq_banks,
> @@ -1425,7 +1434,8 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
> return 0;
>
> clk_error:
> - clk_disable_unprepare(clk);
> + if (clk)
> + clk_disable_unprepare(clk);
> gpiochip_error:
> gpiochip_remove(pctl->chip);
> return ret;
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 11b128f54ed2..ccb6230f0bb5 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -113,6 +113,7 @@ struct sunxi_pinctrl_desc {
> unsigned irq_bank_base;
> bool irq_read_needs_mux;
> bool disable_strict_mode;
> + bool without_bus_gate;
> };
>
> struct sunxi_pinctrl_function {
>
^ permalink raw reply
* [PATCH V4 0/3] Map larger kernels at early init
From: Steve Capper @ 2018-01-11 10:11 UTC (permalink / raw)
To: linux-arm-kernel
The early pagetable creation code assumes that a single pgd, pud, pmd
and pte are sufficient to map the kernel text for MMU bringup. For 16KB
granules this is, unfortunately, rarely the case. Some kernels may be too
big even for a 64KB granule employing this scheme.
This patch series addresses the problem in three steps: 1) re-order the
reserved_ttbr0 to allow its address computation to be independent of
swapper_pg_dir size, 2) re-order the trampoline in a similar manner,
and 3) re-write the early pgtable code to allow for multiple page table
entries at each level.
Changes in v4: Reviewed-by's/Tested-by's added, count logic simplified
in last patch.
Changes in v3: Series rebased on top of arm64/for-next/core branch. This
necessitated changes to accommodate kpti (mainly moving the trampiline page
table before the swapper, in patch #2); as well as 52-bit PA (some assembler
rebasing).
Changes in v2: Ack added to patch #1, KASLR space calculation redone
in patch #2.
Steve Capper (3):
arm64: Re-order reserved_ttbr0 in linker script
arm64: entry: Move the trampoline to be before PAN
arm64: Extend early page table code to allow for larger kernels
arch/arm64/include/asm/asm-uaccess.h | 8 +-
arch/arm64/include/asm/kernel-pgtable.h | 47 ++++++++++-
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/include/asm/uaccess.h | 4 +-
arch/arm64/kernel/entry.S | 4 +-
arch/arm64/kernel/head.S | 144 +++++++++++++++++++++++---------
arch/arm64/kernel/vmlinux.lds.S | 15 ++--
arch/arm64/mm/mmu.c | 3 +-
8 files changed, 171 insertions(+), 55 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH V4 1/3] arm64: Re-order reserved_ttbr0 in linker script
From: Steve Capper @ 2018-01-11 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111101159.9748-1-steve.capper@arm.com>
Currently one resolves the location of the reserved_ttbr0 for PAN by
taking a positive offset from swapper_pg_dir. In a future patch we wish
to extend the swapper s.t. its size is determined at link time rather
than comile time, rendering SWAPPER_DIR_SIZE unsuitable for such a low
level calculation.
In this patch we re-arrange the order of the linker script s.t. instead
one computes reserved_ttbr0 by subtracting RESERVED_TTBR0_SIZE from
swapper_pg_dir.
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
Changed in V4: added Ard's tags
---
arch/arm64/include/asm/asm-uaccess.h | 8 ++++----
arch/arm64/include/asm/uaccess.h | 4 ++--
arch/arm64/kernel/vmlinux.lds.S | 5 ++---
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
index f4f234b6155e..8719ce122a38 100644
--- a/arch/arm64/include/asm/asm-uaccess.h
+++ b/arch/arm64/include/asm/asm-uaccess.h
@@ -13,11 +13,11 @@
*/
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
.macro __uaccess_ttbr0_disable, tmp1
- mrs \tmp1, ttbr1_el1 // swapper_pg_dir
- add \tmp1, \tmp1, #SWAPPER_DIR_SIZE // reserved_ttbr0 at the end of swapper_pg_dir
- msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
+ mrs \tmp1, ttbr1_el1 // swapper_pg_dir
+ sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before swapper_pg_dir
+ msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
isb
- sub \tmp1, \tmp1, #SWAPPER_DIR_SIZE
+ add \tmp1, \tmp1, #RESERVED_TTBR0_SIZE
bic \tmp1, \tmp1, #TTBR_ASID_MASK
msr ttbr1_el1, \tmp1 // set reserved ASID
isb
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 6eadf55ebaf0..e269d35372cf 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -108,8 +108,8 @@ static inline void __uaccess_ttbr0_disable(void)
unsigned long ttbr;
ttbr = read_sysreg(ttbr1_el1);
- /* reserved_ttbr0 placed at the end of swapper_pg_dir */
- write_sysreg(ttbr + SWAPPER_DIR_SIZE, ttbr0_el1);
+ /* reserved_ttbr0 placed before swapper_pg_dir */
+ write_sysreg(ttbr - RESERVED_TTBR0_SIZE, ttbr0_el1);
isb();
/* Set reserved ASID */
ttbr &= ~TTBR_ASID_MASK;
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index ddfd3c0942f7..8e567de8f369 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -218,13 +218,12 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
idmap_pg_dir = .;
. += IDMAP_DIR_SIZE;
- swapper_pg_dir = .;
- . += SWAPPER_DIR_SIZE;
-
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
reserved_ttbr0 = .;
. += RESERVED_TTBR0_SIZE;
#endif
+ swapper_pg_dir = .;
+ . += SWAPPER_DIR_SIZE;
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
tramp_pg_dir = .;
--
2.11.0
^ permalink raw reply related
* [PATCH V4 2/3] arm64: entry: Move the trampoline to be before PAN
From: Steve Capper @ 2018-01-11 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111101159.9748-1-steve.capper@arm.com>
The trampoline page tables are positioned after the early page tables in
the kernel linker script.
As we are about to change the early page table logic to resolve the
swapper size at link time as opposed to compile time, the
SWAPPER_DIR_SIZE variable (currently used to locate the trampline)
will be rendered unsuitable for low level assembler.
This patch solves this issue by moving the trampoline before the PAN
page tables. The offset to the trampoline from ttbr1 can then be
expressed by: PAGE_SIZE + RESERVED_TTBR0_SIZE, which is available to the
entry assembler.
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
Changed in V4: added Ard's tags
---
arch/arm64/kernel/entry.S | 4 ++--
arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 031392ee5f47..7902d8145b9a 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -987,7 +987,7 @@ __ni_sys_trace:
.macro tramp_map_kernel, tmp
mrs \tmp, ttbr1_el1
- sub \tmp, \tmp, #(SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
+ add \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE)
bic \tmp, \tmp, #USER_ASID_FLAG
msr ttbr1_el1, \tmp
#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
@@ -1006,7 +1006,7 @@ alternative_else_nop_endif
.macro tramp_unmap_kernel, tmp
mrs \tmp, ttbr1_el1
- add \tmp, \tmp, #(SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
+ sub \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE)
orr \tmp, \tmp, #USER_ASID_FLAG
msr ttbr1_el1, \tmp
/*
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 8e567de8f369..4c7112a47469 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -218,6 +218,12 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
idmap_pg_dir = .;
. += IDMAP_DIR_SIZE;
+
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ tramp_pg_dir = .;
+ . += PAGE_SIZE;
+#endif
+
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
reserved_ttbr0 = .;
. += RESERVED_TTBR0_SIZE;
@@ -225,11 +231,6 @@ SECTIONS
swapper_pg_dir = .;
. += SWAPPER_DIR_SIZE;
-#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
- tramp_pg_dir = .;
- . += PAGE_SIZE;
-#endif
-
__pecoff_data_size = ABSOLUTE(. - __initdata_begin);
_end = .;
--
2.11.0
^ 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