* Re: [PATCH V5 00/12] 52-bit kernel + user VAs
From: Will Deacon @ 2019-08-14 12:24 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: mark.rutland, Christoph von Recklinghausen, Ard Biesheuvel,
Catalin Marinas, Steve Capper, Linux-Renesas, Geert Uytterhoeven,
maz, Linux ARM
In-Reply-To: <CACi5LpMNC2h-JAmT3gc8wt6rwPBzQaAUZq_P18D3Atjg9CNS5A@mail.gmail.com>
[+Mark]
On Wed, Aug 14, 2019 at 05:29:09PM +0530, Bhupesh Sharma wrote:
> On Wed, Aug 14, 2019 at 1:51 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Wed, Aug 14, 2019 at 01:34:49PM +0530, Bhupesh Sharma wrote:
> > > I still see the following issue on a 48-bit hardware (i.e. _non_
> > > ARMv8.2 hardware) with branch 'for-next/52-bit-kva' with commit
> > > d2d73d2fef421ca0d4 as the HEAD:
> >
> > Have you tried the patches I posted here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/673315.html
> >
> > ?
> >
> > Whilst they're being reviewed, I've dropped the 52-bit branch from
> > linux-next (for-next/core) so that people don't keep running into this.
>
> Thanks will try the above and get back with my results.
>
> However just to make sure that the 52-bit changes are tested properly
> (before landing up linux-next) - as we had issues with the 52-bit User
> space VA + PA changes in the past (which broke userspace), I was
> wondering if we can have a dedicated branch to have the v5 patches
> from Steve + fixes, so that they can be easily tested and issues (if
> any) reported with easy reference.
>
> Or, if such a branch already exists, kindly share the pointer to the
> same as well.
I've pushed the current round of fixes on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/52-bit-kva
Mark has spotted a couple of other issues, but they shoudn't hold up your
testing (although I'm going to hold off putting this back into -next until
we've got them resolved).
Mark -- please use the branch above as a basis for any additional fixes.
HEAD should be d0b3c32ed922.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] Add support of New Amlogic temperature sensor for G12 SoCs
From: Christian Hewitt @ 2019-08-14 12:24 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190806130506.8753-1-glaroque@baylibre.com>
On 6 Aug 2019, at 5:05 pm, Guillaume La Roque <glaroque@baylibre.com> wrote:
>
> This patchs series add support of New Amlogic temperature sensor and minimal
> thermal zone for SEI510 and ODROID-N2 boards.
>
> First implementation was doing on IIO[1] but after comments i move on thermal framework.
> Formulas and calibration values come from amlogic.
>
> Changes since v2:
> - fix yaml documention
> - remove unneeded status variable for temperature-sensor node
> - rework driver after Martin review
> - add some information in commit message
>
> Changes since v1:
> - fix enum vs const in documentation
> - fix error with thermal-sensor-cells value set to 1 instead of 0
> - add some dependencies needed to add cooling-maps
>
> Dependencies :
> - patch 3,4 & 5: depends on Neil's patch and series :
> - missing dwc2 phy-names[2]
> - patchsets to add DVFS on G12a[3] which have deps on [4] and [5]
>
> [1] https://lore.kernel.org/linux-amlogic/20190604144714.2009-1-glaroque@baylibre.com/
> [2] https://lore.kernel.org/linux-amlogic/20190625123647.26117-1-narmstrong@baylibre.com/
> [3] https://lore.kernel.org/linux-amlogic/20190729132622.7566-1-narmstrong@baylibre.com/
> [4] https://lore.kernel.org/linux-amlogic/20190731084019.8451-5-narmstrong@baylibre.com/
> [5] https://lore.kernel.org/linux-amlogic/20190729132622.7566-3-narmstrong@baylibre.com/
>
> Guillaume La Roque (6):
> dt-bindings: thermal: Add DT bindings documentation for Amlogic
> Thermal
> thermal: amlogic: Add thermal driver to support G12 SoCs
> arm64: dts: amlogic: g12: add temperature sensor
> arm64: dts: meson: sei510: Add minimal thermal zone
> arm64: dts: amlogic: odroid-n2: add minimal thermal zone
> MAINTAINERS: add entry for Amlogic Thermal driver
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
I’ve tested this series with Odroid N2 and Khadas VIM3, X96-Max. Patches to add
support for VIM3/X96-max will be submitted once the driver is merged.
VIM3:~ # dmesg | grep thermal
[ 0.046375] thermal_sys: Registered thermal governor 'step_wise'
VIM3:~ # cat /sys/devices/virtual/thermal/thermal_zone0/temp
51300
VIM3:~ # cat /sys/devices/virtual/thermal/thermal_zone1/temp
52800
Christian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] CP115 pinctrl support
From: Thomas Petazzoni @ 2019-08-14 12:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
Rob Herring, Miquel Raynal, Stefan Chulski, Marcin Wojtas,
Linux ARM
In-Reply-To: <CACRpkdbEw5eCKb=nTCK4wuMsPEadEQdGx62cGRhk7F78p5X2CA@mail.gmail.com>
Hello Linus,
On Wed, 14 Aug 2019 10:12:36 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Aug 7, 2019 at 2:47 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > This is the second batch of changes (out of three) to support the brand
> > > new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
> > >
> > > We add a new compatible (and the relevant support in the pinctrl
> > > driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
> >
> > Waiting for review from the Mvebu maintainers.
> >
> > If it takes too long just nudge me, it looks good to me.
>
> So if the other MVEBU maintainers don't really look much at MVEBU
> patches anymore while Miquel is working a lot on the platform,
> what about listing Miquel as maintainer under the SoC entry, hm?
Miquel sent his series on August 5, i.e 9 days ago. We're in August, in
the middle of the summer vacations for many people. While it is nice to
see subsystem maintainers who want to get code merged in a timely
fashion, I think it is probably wise to give it some more time for
review in this period of the year.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Suzuki K Poulose @ 2019-08-14 12:35 UTC (permalink / raw)
To: mike.leach, andrew.murray
Cc: Al.Grant, mathieu.poirier, alexander.shishkin, coresight,
Sudeep.Holla, leo.yan, linux-arm-kernel
In-Reply-To: <CAJ9a7Vj+bo2PMnh2fbMJnaHRwJm9jU689P+iZ4q8_Vg7-3SnDg@mail.gmail.com>
Hi Mike,
On 14/08/2019 12:06, Mike Leach wrote:
> Hi,
>
> On Wed, 14 Aug 2019 at 11:01, Andrew Murray <andrew.murray@arm.com> wrote:
>>
>> On Sun, Aug 04, 2019 at 07:13:45AM -0600, Mathieu Poirier wrote:
>>> On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
>>>>
>>>> On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On 30/07/2019 13:51, Andrew Murray wrote:
>>>>>> Some coresight components, because of choices made during hardware
>>>>>> integration, require their state to be saved and restored across CPU low
>>>>>> power states.
...
>>>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>>>>> @@ -92,6 +92,9 @@ its hardware characteristcs.
>>>>>> * arm,cp14: must be present if the system accesses ETM/PTM management
>>>>>> registers via co-processor 14.
>>>>>> + * arm,coresight-needs-save-restore: boolean. Indicates that software
>>>>>> + should save/restore state across power down.
>>>>>> +
>>>>>
>>>>> Do you think we could be a bit more descriptive here about when people could add
>>>>> it to the DT ? Here we don't mention when someone should use this property and
>>>>> it may be added to platforms where it may be absolutely unnecessary. How about :
>>>>>
>>>>> "Indicates that the hardware implementation may not honor the Powerup request
>>>>> from the software and thus might loose the register context on CPU power
>>>>> down (e.g, during CPUIdle). Software must save/restore the context during a
>>>>> CPU power transition cycle."
>>>>
>>>> How about the following:
>>>>
>>>> "Indicates that the hardware will loose register context on CPU power down (e.g.
>>>> CPUIdle), despite the TRCPDCR.PU bit being set."
>>>>
>>>> I'm keen to avoid making suggestions about what the kernel will do when it sees
>>>> this flag and thus prefer to focus on describing what the hardware does. So I
>>>> dropped your last sentence. However the name of the flag still implies policy
>>>> which I don't like.
>>>>
>>>> I also changed the 'may not honor' wording, I'm not sure if this is really the
>>>> case or if the spec is open to interpretation.
>>>>
>>>> It would great for this wording to also apply to other CS components though I
>>>> haven't investigated if these have a PU bit or something different.
>>>
>>> Exactly - the definition needs to be broad enough to apply to other CS
>>> components. Mike what do you think would be appropriate for CTIs?
>>
> CTIs have no power control at all - i.e. no PU bit to request we stay
> up - and reside in the debug power domain. So they are coupled to the
> CS/CPU/ETM/ power domains and reliant on outside forces to request
> power.
> The expectation is that for a PE bound CTI, if debug is powered then
> it will be fully powered - so an ETM with PU respected, or the
> external debug logic with DBGNOPWRDWN respected should be sufficient
> for CTI to stay alive.
I am trying to understand why we need this property for CTI.
Don't we always need to save-restore the CTI controls on a CPU_DOWN for the
associated CTI ? Since it may not be really tied to an ETM (e.g, if the CTI is
purely used to handle CPU triggers, PMU etc,). If that is the case, do we need
this property for CTI at all ?
>
>> How about we keep this short and simple:
>>
>> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
nit: s/loses/looses ?
>> will lose register context on CPU power down (e.g. CPUIdle).
>>
>
> So the above name is generic enough to encompass the CTI as well.
>
>> I could have added something like "... despite TRCPDCR.PU being set", or to
>> apply more generically: "... despite available register controls being set to
>> prevent such context loss". However whilst these are more informative - they
>> elude to some of reasons as to why context is lost and as we cannot be
>> exhaustive I'd rather not give a limited example.
>>
>> However if a longer explaination is required:
>>
>> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
>> will lose register context on CPU power down (e.g. CPUIdle). An example of
>> where this may be needed are systems which contain a coresight component and
>> CPU in the same power domain. When the CPU powers down the coresight
>> component also powers down and loses its context.
This looks fine for me. But I am trying to understand the rationale behind
using this for CTI
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Andrew Murray @ 2019-08-14 12:49 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Al.Grant, mathieu.poirier, alexander.shishkin, coresight, leo.yan,
Sudeep.Holla, linux-arm-kernel, mike.leach
In-Reply-To: <718b5bdf-9828-f215-9a81-637308be3b49@arm.com>
On Wed, Aug 14, 2019 at 01:35:27PM +0100, Suzuki K Poulose wrote:
> Hi Mike,
>
> On 14/08/2019 12:06, Mike Leach wrote:
> > Hi,
> >
> > On Wed, 14 Aug 2019 at 11:01, Andrew Murray <andrew.murray@arm.com> wrote:
> > >
> > > On Sun, Aug 04, 2019 at 07:13:45AM -0600, Mathieu Poirier wrote:
> > > > On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
> > > > >
> > > > > On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
> > > > > > Hi Andrew,
> > > > > >
> > > > > > On 30/07/2019 13:51, Andrew Murray wrote:
> > > > > > > Some coresight components, because of choices made during hardware
> > > > > > > integration, require their state to be saved and restored across CPU low
> > > > > > > power states.
>
> ...
>
> > > > > > > --- a/Documentation/devicetree/bindings/arm/coresight.txt
> > > > > > > +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> > > > > > > @@ -92,6 +92,9 @@ its hardware characteristcs.
> > > > > > > * arm,cp14: must be present if the system accesses ETM/PTM management
> > > > > > > registers via co-processor 14.
> > > > > > > + * arm,coresight-needs-save-restore: boolean. Indicates that software
> > > > > > > + should save/restore state across power down.
> > > > > > > +
> > > > > >
> > > > > > Do you think we could be a bit more descriptive here about when people could add
> > > > > > it to the DT ? Here we don't mention when someone should use this property and
> > > > > > it may be added to platforms where it may be absolutely unnecessary. How about :
> > > > > >
> > > > > > "Indicates that the hardware implementation may not honor the Powerup request
> > > > > > from the software and thus might loose the register context on CPU power
> > > > > > down (e.g, during CPUIdle). Software must save/restore the context during a
> > > > > > CPU power transition cycle."
> > > > >
> > > > > How about the following:
> > > > >
> > > > > "Indicates that the hardware will loose register context on CPU power down (e.g.
> > > > > CPUIdle), despite the TRCPDCR.PU bit being set."
> > > > >
> > > > > I'm keen to avoid making suggestions about what the kernel will do when it sees
> > > > > this flag and thus prefer to focus on describing what the hardware does. So I
> > > > > dropped your last sentence. However the name of the flag still implies policy
> > > > > which I don't like.
> > > > >
> > > > > I also changed the 'may not honor' wording, I'm not sure if this is really the
> > > > > case or if the spec is open to interpretation.
> > > > >
> > > > > It would great for this wording to also apply to other CS components though I
> > > > > haven't investigated if these have a PU bit or something different.
> > > >
> > > > Exactly - the definition needs to be broad enough to apply to other CS
> > > > components. Mike what do you think would be appropriate for CTIs?
> > >
> > CTIs have no power control at all - i.e. no PU bit to request we stay
> > up - and reside in the debug power domain. So they are coupled to the
> > CS/CPU/ETM/ power domains and reliant on outside forces to request
> > power.
> > The expectation is that for a PE bound CTI, if debug is powered then
> > it will be fully powered - so an ETM with PU respected, or the
> > external debug logic with DBGNOPWRDWN respected should be sufficient
> > for CTI to stay alive.
>
> I am trying to understand why we need this property for CTI.
> Don't we always need to save-restore the CTI controls on a CPU_DOWN for the
> associated CTI ? Since it may not be really tied to an ETM (e.g, if the CTI is
> purely used to handle CPU triggers, PMU etc,). If that is the case, do we need
> this property for CTI at all ?
>
> >
> > > How about we keep this short and simple:
> > >
> > > * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
>
> nit: s/loses/looses ?
Given that lose refers to missing something and loose refers to something not fitting
well, I'd have thought the pural is loses. Though I've now looked at these words for
too long and nothing makes sense any more...
>
> > > will lose register context on CPU power down (e.g. CPUIdle).
> > >
> >
> > So the above name is generic enough to encompass the CTI as well.
> >
> > > I could have added something like "... despite TRCPDCR.PU being set", or to
> > > apply more generically: "... despite available register controls being set to
> > > prevent such context loss". However whilst these are more informative - they
> > > elude to some of reasons as to why context is lost and as we cannot be
> > > exhaustive I'd rather not give a limited example.
> > >
> > > However if a longer explaination is required:
> > >
> > > * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
> > > will lose register context on CPU power down (e.g. CPUIdle). An example of
> > > where this may be needed are systems which contain a coresight component and
> > > CPU in the same power domain. When the CPU powers down the coresight
> > > component also powers down and loses its context.
>
> This looks fine for me. But I am trying to understand the rationale behind
> using this for CTI
Thanks.
Thanks,
Andrew Murray
>
> Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] ARM: psci: cpuidle: defconfig updates
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Catalin Marinas,
Will Deacon, Daniel Lezcano, Sudeep Holla, Shawn Guo, LAKML
Rerouting defconfig updates related to this patch series:
https://lore.kernel.org/linux-arm-kernel/cover.1565348376.git.lorenzo.pieralisi@arm.com/
to arm-soc, as agreed in:
https://lore.kernel.org/linux-arm-kernel/58d9677db3510ed106fe23118090c84f78a44102.1565348376.git.lorenzo.pieralisi@arm.com/
Patches [1-6] are already queued in the ARM64 tree.
Please consider pulling these defconfig changes, thank you very much.
Cc: Will Deacon <will@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Lorenzo Pieralisi (2):
arm64: defconfig: Enable the PSCI CPUidle driver
ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
2 files changed, 2 insertions(+)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Will Deacon,
Catalin Marinas, Daniel Lezcano, Sudeep Holla, Shawn Guo, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
Enable the PSCI CPUidle driver to replace the functionality
previously provided by the generic ARM CPUidle driver.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index a53b29251ed4..4174fd1b79e7 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -60,6 +60,7 @@ CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_ARM_IMX_CPUFREQ_DT=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
+CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_PM_DEBUG=y
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] arm64: defconfig: Enable the PSCI CPUidle driver
From: Lorenzo Pieralisi @ 2019-08-14 12:52 UTC (permalink / raw)
To: soc
Cc: Mark Rutland, Ulf Hansson, Lorenzo Pieralisi, Catalin Marinas,
Daniel Lezcano, Sudeep Holla, Shawn Guo, Will Deacon, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
Enable the PSCI CPUidle driver to replace the functionality
previously provided by the generic ARM CPUidle driver through
CPU operations.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..c0a7cfe3aebd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -72,6 +72,7 @@ CONFIG_RANDOMIZE_BASE=y
CONFIG_HIBERNATION=y
CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
CONFIG_ARM_CPUIDLE=y
+CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: kexec on rk3399
From: Vicente Bergas @ 2019-08-14 12:53 UTC (permalink / raw)
To: Felipe Balbi, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <ebcb52be-2063-4e2c-9a09-fdcacb94f855@gmail.com>
On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
> From 5.2 onwards, there are memory corruption issues as reported here:
> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
> kexec has been identified as the principal reason for the issues.
>
> It turns out that kexec has never worked reliably on this platform,
> i was just lucky until recently.
>
> Please, can you provide some directions on how to debug the issue?
Thank you all for your suggestions on where the issue could be.
It seems that it was the USB driver.
Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
so far so good. It is being tested on the Sapphire board.
The workaround is:
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -133,6 +133,13 @@
return 0;
}
+static void dwc3_of_simple_shutdown(struct platform_device *pdev)
+{
+ struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
+
+ reset_control_assert(simple->resets);
+}
+
static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
*dev)
{
struct dwc3_of_simple *simple = dev_get_drvdata(dev);
@@ -190,6 +197,7 @@
static struct platform_driver dwc3_of_simple_driver = {
.probe = dwc3_of_simple_probe,
.remove = dwc3_of_simple_remove,
+ .shutdown = dwc3_of_simple_shutdown,
.driver = {
.name = "dwc3-of-simple",
.of_match_table = of_dwc3_simple_match,
If this patch is OK after review i can resubmit it as a pull request.
Should a similar change be applied to drivers/usb/dwc3/core.c ?
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] i2c: stm32: Use the correct style for SPDX License Identifier
From: Wolfram Sang @ 2019-08-14 12:58 UTC (permalink / raw)
To: Nishad Kamdar
Cc: Alexandre Torgue, Greg Kroah-Hartman, linux-kernel,
Pierre-Yves MORDRET, linux-i2c, Maxime Coquelin,
Uwe Kleine-König, Joe Perches, linux-stm32, linux-arm-kernel
In-Reply-To: <20190803141331.GA3588@nishad>
[-- Attachment #1.1: Type: text/plain, Size: 665 bytes --]
On Sat, Aug 03, 2019 at 07:43:35PM +0530, Nishad Kamdar wrote:
> This patch corrects the SPDX License Identifier style
> in header file related to STM32 Driver for I2C hardware
> bus support.
> For C header files Documentation/process/license-rules.rst
> mandates C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Pierre-Yves is on holiday and this patch is obviously correct, so
applied to for-current, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver
From: Krzysztof Kozlowski @ 2019-08-14 12:58 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-4-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:08, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating
> points depending on exact revision of an SoC retrieved from the CHIPID
> block or the OTP memory. This allows for some power saving as for some
> CPU clock frequencies we can lower CPU cluster supply voltage comparing
> to safe values common to the all chip revisions.
>
> This patch adds support for Exynos5422/5800 SoC, it is partially based
> on code from https://github.com/hardkernel/linux repository,
> branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch].
>
> Tested on Odroid XU3, XU4, XU3 Lite.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
> - Use devm_kzalloc() in probe() to avoid memory leak,
> - removed leading spaces in exynos-chipid.h,
> - removed unneeded <linux/init.h> header inclusion,
> - dropped parentheses from exynos542_asv_parse_sg(),
> - updated Kconfig entry,
> - added const attribute to struct exynos_asv_susbsys::cpu_dt_compat.
>
> Changes since v1 (RFC):
> - removed code for parsing the ASV OPP tables from DT, the ASV OPP tables
> moved to the driver;
> - converted to use the regmap API;
> - converted to normal platform driver.
> ---
> drivers/soc/samsung/Kconfig | 10 +
> drivers/soc/samsung/Makefile | 3 +
> drivers/soc/samsung/exynos-asv.c | 184 ++++++++++
> drivers/soc/samsung/exynos-asv.h | 82 +++++
> drivers/soc/samsung/exynos5422-asv.c | 498 +++++++++++++++++++++++++++
> drivers/soc/samsung/exynos5422-asv.h | 25 ++
> 6 files changed, 802 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-asv.c
> create mode 100644 drivers/soc/samsung/exynos-asv.h
> create mode 100644 drivers/soc/samsung/exynos5422-asv.c
> create mode 100644 drivers/soc/samsung/exynos5422-asv.h
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2905f5262197..73ccf59676a1 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -7,6 +7,16 @@ menuconfig SOC_SAMSUNG
>
> if SOC_SAMSUNG
>
> +config EXYNOS_ASV
> + bool "Exynos Adaptive Supply Voltage support" if COMPILE_TEST
> + depends on (ARCH_EXYNOS && EXYNOS_CHIPID) || COMPILE_TEST
> + select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
> +
> +# There is no need to enable these drivers for ARMv8
> +config EXYNOS_ASV_ARM
> + bool "Exynos ASV ARMv7-specific driver extensions" if COMPILE_TEST
> + depends on EXYNOS_ASV
> +
> config EXYNOS_CHIPID
> bool "Exynos Chipid controller driver" if COMPILE_TEST
> depends on ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index 3b6a8797416c..edd1d6ea064d 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -1,5 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0
>
> +obj-$(CONFIG_EXYNOS_ASV) += exynos-asv.o
> +obj-$(CONFIG_EXYNOS_ASV_ARM) += exynos5422-asv.o
> +
> obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
> obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
>
> diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
> new file mode 100644
> index 000000000000..481deb600afc
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-asv.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Samsung Exynos SoC Adaptive Supply Voltage support
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
> +#include <linux/regmap.h>
> +#include <linux/soc/samsung/exynos-chipid.h>
> +
> +#include "exynos-asv.h"
> +#include "exynos5422-asv.h"
> +
> +#define MHZ 1000000U
> +
> +static int exynos_asv_update_cpu_opps(struct exynos_asv *asv,
> + struct device *cpu)
> +{
> + struct exynos_asv_subsys *subsys = NULL;
> + struct dev_pm_opp *opp;
> + unsigned int opp_freq;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(asv->subsys); i++) {
> + if (of_device_is_compatible(cpu->of_node,
> + asv->subsys[i].cpu_dt_compat)) {
> + subsys = &asv->subsys[i];
> + break;
> + }
> + }
> + if (!subsys)
> + return -EINVAL;
> +
> + for (i = 0; i < subsys->table.num_rows; i++) {
> + unsigned int new_voltage;
> + unsigned int voltage;
> + int timeout = 1000;
> + int err;
> +
> + opp_freq = exynos_asv_opp_get_frequency(subsys, i);
> +
> + opp = dev_pm_opp_find_freq_exact(cpu, opp_freq * MHZ, true);
> + if (IS_ERR(opp)) {
> + dev_info(asv->dev, "cpu%d opp%d, freq: %u missing\n",
> + cpu->id, i, opp_freq);
> +
> + continue;
> + }
> +
> + voltage = dev_pm_opp_get_voltage(opp);
> + new_voltage = asv->opp_get_voltage(subsys, i, voltage);
> + dev_pm_opp_put(opp);
> +
> + opp_freq *= MHZ;
> + dev_pm_opp_remove(cpu, opp_freq);
> +
> + while (--timeout) {
> + opp = dev_pm_opp_find_freq_exact(cpu, opp_freq, true);
> + if (IS_ERR(opp))
> + break;
> + dev_pm_opp_put(opp);
> + msleep(1);
> + }
> +
> + err = dev_pm_opp_add(cpu, opp_freq, new_voltage);
> + if (err < 0)
> + dev_err(asv->dev,
> + "Failed to add OPP %u Hz/%u uV for cpu%d\n",
> + opp_freq, new_voltage, cpu->id);
> + }
> +
> + return 0;
> +}
> +
> +static int exynos_asv_update_opps(struct exynos_asv *asv)
> +{
> + struct opp_table *last_opp_table = NULL;
> + struct device *cpu;
> + int ret, cpuid;
> +
> + for_each_possible_cpu(cpuid) {
> + struct opp_table *opp_table;
> +
> + cpu = get_cpu_device(cpuid);
> + if (!cpu)
> + continue;
> +
> + opp_table = dev_pm_opp_get_opp_table(cpu);
> + if (IS_ERR(opp_table))
> + continue;
> +
> + if (!last_opp_table || opp_table != last_opp_table) {
> + last_opp_table = opp_table;
> +
> + ret = exynos_asv_update_cpu_opps(asv, cpu);
> + if (ret < 0)
> + dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
> + cpuid);
> + }
> +
> + dev_pm_opp_put_opp_table(opp_table);
> + }
> +
> + return 0;
> +}
> +
> +static int exynos_asv_probe(struct platform_device *pdev)
> +{
> + int (*probe_func)(struct exynos_asv *asv);
> + struct exynos_asv *asv;
> + struct device *cpu_dev;
> + u32 product_id = 0;
> + int ret, i;
> +
> + cpu_dev = get_cpu_device(0);
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret < 0)
> + return -EPROBE_DEFER;
> +
> + asv = devm_kzalloc(&pdev->dev, sizeof(*asv), GFP_KERNEL);
> + if (!asv)
> + return -ENOMEM;
> +
> + asv->chipid_regmap = syscon_node_to_regmap(pdev->dev.of_node);
> + if (IS_ERR(asv->chipid_regmap)) {
> + dev_err(&pdev->dev, "Could not find syscon regmap\n");
> + return PTR_ERR(asv->chipid_regmap);
> + }
> +
> + regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID, &product_id);
> +
> + switch (product_id & EXYNOS_MASK) {
> + case 0xE5422000:
> + probe_func = exynos5422_asv_init;
> + break;
> + default:
> + dev_err(&pdev->dev, "Unsupported product ID: %#x", product_id);
> + return -ENODEV;
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "samsung,asv-bin",
> + &asv->of_bin);
> + if (ret < 0)
> + asv->of_bin = -EINVAL;
> +
> + asv->dev = &pdev->dev;
> + dev_set_drvdata(&pdev->dev, asv);
> +
> + for (i = 0; i < ARRAY_SIZE(asv->subsys); i++)
> + asv->subsys[i].asv = asv;
> +
> + ret = probe_func(asv);
> + if (ret < 0)
> + return ret;
> +
> + return exynos_asv_update_opps(asv);
> +}
> +
> +static const struct of_device_id exynos_asv_of_device_ids[] = {
> + { .compatible = "samsung,exynos4210-chipid" },
> + {}
> +};
> +
> +static struct platform_driver exynos_asv_driver = {
> + .driver = {
> + .name = "exynos-asv",
> + .of_match_table = exynos_asv_of_device_ids,
> + },
> + .probe = exynos_asv_probe,
> +};
> +module_platform_driver(exynos_asv_driver);
> diff --git a/drivers/soc/samsung/exynos-asv.h b/drivers/soc/samsung/exynos-asv.h
> new file mode 100644
> index 000000000000..14b4fedf2ddd
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-asv.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2019 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Samsung Exynos SoC Adaptive Supply Voltage support
> + */
> +#ifndef __LINUX_SOC_EXYNOS_ASV_H
> +#define __LINUX_SOC_EXYNOS_ASV_H
Yikes, that was my mistake. The file is in drivers/soc, not include,
so this could stay as previous one. Or make more path dependend -
__DRIVERS_SOC... Now it is inconsistent with
drivers/soc/samsung/exynos5422-asv.h.
I can fixup these two files while applying but if there is going to be
a resend, then change both to __DRIVERS_SOC_..._H.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 7/9] soc: samsung: Update the CHIP ID DT binding documentation
From: Krzysztof Kozlowski @ 2019-08-14 13:00 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-8-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:09, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> This patch adds documentation of a new optional "samsung,asv-bin"
> property in the chipid device node and documents requirement of
> "syscon" compatible string. These additions are needed to support
> Exynos ASV (Adaptive Supply Voltage) feature.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes since v2:
> - none
>
> Changes since v1 (RFC):
> - new patch
> ---
> .../devicetree/bindings/arm/samsung/exynos-chipid.txt | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> index 85c5dfd4a720..be3657e6c00c 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
> @@ -1,12 +1,18 @@
> -SAMSUNG Exynos SoCs Chipid driver.
> +SAMSUNG Exynos SoC series CHIPID subsystem
>
> Required properties:
> -- compatible : Should at least contain "samsung,exynos4210-chipid".
> +- compatible : Should at least contain "samsung,exynos4210-chipid", "syscon".
>
> - reg: offset and length of the register set
>
> +Optional properties:
> + - samsung,asv-bin : Adaptive Supply Voltage bin selection. This can be used
> + to determine the ASV bin of an SoC if respective information is missing
> + in the CHIPID registers or in the OTP memory. Possible values: 0...3.
> +
> Example:
> chipid@10000000 {
> compatible = "samsung,exynos4210-chipid";
Please update the example with new required compatible.
Best regards,
Krzysztof
> reg = <0x10000000 0x100>;
> + samsung,asv-bin = <2>;
> };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/9] arm64: Stolen time support
From: Alexander Graf @ 2019-08-14 13:02 UTC (permalink / raw)
To: Steven Price, Marc Zyngier
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <6789f477-8ab5-cc54-1ad2-8627917b07c9@arm.com>
On 05.08.19 15:06, Steven Price wrote:
> On 03/08/2019 19:05, Marc Zyngier wrote:
>> On Fri, 2 Aug 2019 15:50:08 +0100
>> Steven Price <steven.price@arm.com> wrote:
>>
>> Hi Steven,
>>
>>> This series add support for paravirtualized time for arm64 guests and
>>> KVM hosts following the specification in Arm's document DEN 0057A:
>>>
>>> https://developer.arm.com/docs/den0057/a
>>>
>>> It implements support for stolen time, allowing the guest to
>>> identify time when it is forcibly not executing.
>>>
>>> It doesn't implement support for Live Physical Time (LPT) as there are
>>> some concerns about the overheads and approach in the above
>>> specification, and I expect an updated version of the specification to
>>> be released soon with just the stolen time parts.
>>
>> Thanks for posting this.
>>
>> My current concern with this series is around the fact that we allocate
>> memory from the kernel on behalf of the guest. It is the first example
>> of such thing in the ARM port, and I can't really say I'm fond of it.
>>
>> x86 seems to get away with it by having the memory allocated from
>> userspace, why I tend to like more. Yes, put_user is more
>> expensive than a straight store, but this isn't done too often either.
>>
>> What is the rational for your current approach?
>
> As I see it there are 3 approaches that can be taken here:
>
> 1. Hypervisor allocates memory and adds it to the virtual machine. This
> means that everything to do with the 'device' is encapsulated behind the
> KVM_CREATE_DEVICE / KVM_[GS]ET_DEVICE_ATTR ioctls. But since we want the
> stolen time structure to be fast it cannot be a trapping region and has
> to be backed by real memory - in this case allocated by the host kernel.
>
> 2. Host user space allocates memory. Similar to above, but this time
> user space needs to manage the memory region as well as the usual
> KVM_CREATE_DEVICE dance. I've no objection to this, but it means
> kvmtool/QEMU needs to be much more aware of what is going on (e.g. how
> to size the memory region).
You ideally want to get the host overhead for a VM to as little as you
can. I'm not terribly fond of the idea of reserving a full page just
because we're too afraid of having the guest donate memory.
>
> 3. Guest kernel "donates" the memory to the hypervisor for the
> structure. As far as I'm aware this is what x86 does. The problems I see
> this approach are:
>
> a) kexec becomes much more tricky - there needs to be a disabling
> mechanism for the guest to stop the hypervisor scribbling on memory
> before starting the new kernel.
I wouldn't call "quiesce a device" much more tricky. We have to do that
for other devices as well today.
> b) If there is more than one entity that is interested in the
> information (e.g. firmware and kernel) then this requires some form of
> arbitration in the guest because the hypervisor doesn't want to have to
> track an arbitrary number of regions to update.
Why would FW care?
> c) Performance can suffer if the host kernel doesn't have a suitably
> aligned/sized area to use. As you say - put_user() is more expensive.
Just define the interface to always require natural alignment when
donating a memory location?
> The structure is updated on every return to the VM.
If you really do suffer from put_user(), there are alternatives. You
could just map the page on the registration hcall and then leave it
pinned until the vcpu gets destroyed again.
> Of course x86 does prove the third approach can work, but I'm not sure
> which is actually better. Avoid the kexec cancellation requirements was
> the main driver of the current approach. Although many of the
I really don't understand the problem with kexec cancellation. Worst
case, let guest FW set it up for you and propagate only the address down
via ACPI/DT. That way you can mark the respective memory as reserved too.
But even with a Linux only mechanism, just take a look at
arch/x86/kernel/kvmclock.c. All they do to remove the map is to hook
into machine_crash_shutdown() and machine_shutdown().
Alex
> conversations about this were also tied up with Live Physical Time which
> adds its own complications.
>
> Steve
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/9] Exynos Adaptive Supply Voltage support
From: Krzysztof Kozlowski @ 2019-08-14 13:03 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190813150827.31972-1-s.nawrocki@samsung.com>
On Tue, 13 Aug 2019 at 17:08, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> This is third iteration of my patch series adding ASV (Adaptive Supply
> Voltage) support for Exynos SoCs. The previous one can be found at:
> https://lore.kernel.org/lkml/20190718143044.25066-1-s.nawrocki@samsung.com
>
> There is no major changes in this series comparing to v2, only minor
> corrections addressing review comments.
>
> I was not sure it was a good idea to try to extend the OPP binding
> so as to include the ASV data tables in DT, so the tables are left
> in the driver.
>
> This patch set includes Exynos CHIPID driver posted by Pankaj Dubey and
> futher improved by Bartłomiej Żołnierkiewicz [1].
>
> Tested on Odroid XU3, XU3 Lite, XU4.
>
> One of the things on TODO list is support for the Adaptive Body Bias.
> This will require modifications on the cpufreq driver side in order to
> support multiple voltage regulators and changes in the OPP framework
> to support adding OPPs with multiple voltages.
>
> [1] https://lkml.org/lkml/2018/11/15/908
>
> Pankaj Dubey (3):
> soc: samsung: Add exynos chipid driver support
> ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
> ARM64: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
>
> Sylwester Nawrocki (6):
> soc: samsung: Convert exynos-chipid driver to use the regmap API
> soc: samsung: Add Exynos Adaptive Supply Voltage driver
> ARM: EXYNOS: Enable exynos-asv driver for ARCH_EXYNOS
> soc: samsung: Update the CHIP ID DT binding documentation
> ARM: dts: Add "syscon" compatible string to chipid node
> ARM: dts: Add samsung,asv-bin property for odroidxu3-lite
All look good to me but I need acks for bindings before applying.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Felipe Balbi @ 2019-08-14 13:06 UTC (permalink / raw)
To: Vicente Bergas, Robin Murphy
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <c6993a1e-6fc2-44ab-b59e-152142e2ff4d@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2085 bytes --]
Hi,
Vicente Bergas <vicencb@gmail.com> writes:
> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>> From 5.2 onwards, there are memory corruption issues as reported here:
>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>> kexec has been identified as the principal reason for the issues.
>>
>> It turns out that kexec has never worked reliably on this platform,
>> i was just lucky until recently.
>>
>> Please, can you provide some directions on how to debug the issue?
>
> Thank you all for your suggestions on where the issue could be.
>
> It seems that it was the USB driver.
> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
> so far so good. It is being tested on the Sapphire board.
>
> The workaround is:
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,13 @@
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
> +
> + reset_control_assert(simple->resets);
> +}
> +
> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
> *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +197,7 @@
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
>
> If this patch is OK after review i can resubmit it as a pull request.
not a pull request, just send a patch using git send-email
> Should a similar change be applied to drivers/usb/dwc3/core.c ?
Is it necessary? We haven't had any bug reports regarding that. Also, if
we have reset control support in the core driver, why do we need it in
of_simple? Seems like of_simple could just rely on what core does.
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:07 UTC (permalink / raw)
To: Clément Péron
Cc: Mark Rutland, devicetree, linux-sunxi, linux-kernel, mripard,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel
In-Reply-To: <CAJiuCccEQFvKemTodJbuEDzDy9j6-M4SYskxPFJ5DpsbQDnvkA@mail.gmail.com>
On Thu, Aug 08, 2019 at 04:50:35PM +0200, Clément Péron wrote:
> Hi,
>
> On Thu, 8 Aug 2019 at 10:42, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> >
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
>
> You also need to add the board in
> "Documentation/devicetree/bindings/arm/sunxi.yaml"
>
> Regards,
> Clément
>
Done, thanks
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Robin Murphy @ 2019-08-14 13:12 UTC (permalink / raw)
To: Vicente Bergas, Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, linux-arm-kernel
In-Reply-To: <c6993a1e-6fc2-44ab-b59e-152142e2ff4d@gmail.com>
On 14/08/2019 13:53, Vicente Bergas wrote:
> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>> From 5.2 onwards, there are memory corruption issues as reported here:
>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>> kexec has been identified as the principal reason for the issues.
>>
>> It turns out that kexec has never worked reliably on this platform,
>> i was just lucky until recently.
>>
>> Please, can you provide some directions on how to debug the issue?
>
> Thank you all for your suggestions on where the issue could be.
>
> It seems that it was the USB driver.
> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
> so far so good. It is being tested on the Sapphire board.
>
> The workaround is:
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -133,6 +133,13 @@
> return 0;
> }
>
> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
> +{
> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
> +
> + reset_control_assert(simple->resets);
> +}
> +
> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
> *dev)
> {
> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
> @@ -190,6 +197,7 @@
> static struct platform_driver dwc3_of_simple_driver = {
> .probe = dwc3_of_simple_probe,
> .remove = dwc3_of_simple_remove,
> + .shutdown = dwc3_of_simple_shutdown,
> .driver = {
> .name = "dwc3-of-simple",
> .of_match_table = of_dwc3_simple_match,
>
> If this patch is OK after review i can resubmit it as a pull request.
> Should a similar change be applied to drivers/usb/dwc3/core.c ?
This particular change looks like it's implicitly specific to RK3399,
which wouldn't be ideal. Presumably if the core dwc3 driver implemented
shutdown correctly (echoing parts of dwc3_remove(), I guess) then the
glue layers shouldn't need anything special anyway.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kexec on rk3399
From: Vicente Bergas @ 2019-08-14 13:15 UTC (permalink / raw)
To: Felipe Balbi
Cc: Matthias Brugger, Heiko Stuebner, Marc Zyngier, Catalin Marinas,
linux-usb, Will Deacon, linux-kernel, linux-rockchip,
Greg Kroah-Hartman, Robin Murphy, linux-arm-kernel
In-Reply-To: <87v9uzaocj.fsf@gmail.com>
On Wednesday, August 14, 2019 3:06:04 PM CEST, Felipe Balbi wrote:
> Hi,
>
> Vicente Bergas <vicencb@gmail.com> writes:
>> On Monday, July 22, 2019 4:31:27 PM CEST, Vicente Bergas wrote:
>>> Hi, i have been running linux on rk3399 booted with kexec fine until 5.2
>>> From 5.2 onwards, there are memory corruption issues as reported here:
>>> http://lkml.iu.edu/hypermail/linux/kernel/1906.2/07211.html
>>> kexec has been identified as the principal reason for the issues.
>>>
>>> It turns out that kexec has never worked reliably on this platform, ...
>>
>> Thank you all for your suggestions on where the issue could be.
>>
>> It seems that it was the USB driver.
>> Now using v5.2.8 booted with kexec from v5.2.8 with a workaround and
>> so far so good. It is being tested on the Sapphire board.
>>
>> The workaround is:
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -133,6 +133,13 @@
>> return 0;
>> }
>>
>> +static void dwc3_of_simple_shutdown(struct platform_device *pdev)
>> +{
>> + struct dwc3_of_simple *simple = platform_get_drvdata(pdev);
>> +
>> + reset_control_assert(simple->resets);
>> +}
>> +
>> static int __maybe_unused dwc3_of_simple_runtime_suspend(struct device
>> *dev)
>> {
>> struct dwc3_of_simple *simple = dev_get_drvdata(dev);
>> @@ -190,6 +197,7 @@
>> static struct platform_driver dwc3_of_simple_driver = {
>> .probe = dwc3_of_simple_probe,
>> .remove = dwc3_of_simple_remove,
>> + .shutdown = dwc3_of_simple_shutdown,
>> .driver = {
>> .name = "dwc3-of-simple",
>> .of_match_table = of_dwc3_simple_match,
>>
>> If this patch is OK after review i can resubmit it as a pull request.
>
> not a pull request, just send a patch using git send-email
>
>> Should a similar change be applied to drivers/usb/dwc3/core.c ?
>
> Is it necessary? We haven't had any bug reports regarding that. Also, if
> we have reset control support in the core driver, why do we need it in
> of_simple? Seems like of_simple could just rely on what core does.
the workaround has been tested patching only core.c with
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1561,6 +1561,13 @@
return 0;
}
+static void dwc3_shutdown(struct platform_device *pdev)
+{
+ struct dwc3 *dwc = platform_get_drvdata(pdev);
+
+ reset_control_assert(dwc->reset);
+}
+
#ifdef CONFIG_PM
static int dwc3_core_init_for_resume(struct dwc3 *dwc)
{
@@ -1866,6 +1873,7 @@
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = dwc3_remove,
+ .shutdown = dwc3_shutdown,
.driver = {
.name = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),
and leaving dwc3-of-simple.c as is, the issue persisted.
Regards,
Vicenç.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190812094000.ebdmhyxx7xzbevef@flea>
On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > 2 files changed, 27 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > index f6db0611cb85..9a02166cbf72 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > new file mode 100644
> > index 000000000000..d8ff02747efe
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > @@ -0,0 +1,26 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > + */
> > +
> > +#include "sun50i-h6-pine-h64.dts"
> > +
> > +/ {
> > + model = "Pine H64 model A evaluation board";
> > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > +
> > + reg_gmac_3v3: gmac-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-gmac-3v3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + startup-delay-us = <100000>;
> > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > +};
> > +
> > +&emac {
> > + phy-supply = <®_gmac_3v3>;
> > +};
>
> I might be missing some context here, but I'm pretty sure that the
> initial intent of the pine h64 DTS was to support the model A all
> along.
>
The regulator changed between modelA and B.
See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
From: Mark Rutland @ 2019-08-14 13:18 UTC (permalink / raw)
To: Will Deacon
Cc: Steve Capper, Andrey Konovalov, Geert Uytterhoeven,
Catalin Marinas, Qian Cai, linux-arm-kernel
In-Reply-To: <20190814115959.7epzszx53bidti7m@willie-the-truck>
On Wed, Aug 14, 2019 at 01:00:00PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 12:23:39PM +0100, Mark Rutland wrote:
> > On Tue, Aug 13, 2019 at 06:01:46PM +0100, Will Deacon wrote:
> > > Rather than subtracting from -1 and then adding 1, we can simply
> > > subtract from 0.
> > >
> > > Cc: Steve Capper <steve.capper@arm.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > ---
> > > arch/arm64/include/asm/memory.h | 6 ++----
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 56be462c69ce..5552c8cba1e2 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -44,8 +44,7 @@
> > > * VA_START - the first kernel virtual address.
> > > */
> > > #define VA_BITS (CONFIG_ARM64_VA_BITS)
> > > -#define _PAGE_OFFSET(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << (va)) + 1)
> > > +#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
> > > #define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
> > > #define KIMAGE_VADDR (MODULES_END)
> > > #define BPF_JIT_REGION_START (KASAN_SHADOW_END)
> > > @@ -63,8 +62,7 @@
> > > #else
> > > #define VA_BITS_MIN (VA_BITS)
> > > #endif
> > > -#define _VA_START(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << ((va) - 1)) + 1)
> > > +#define _VA_START(va) (-(UL(1) << ((va) - 1)))
> >
> > This didn't make any sense to me until I realised that we changed the
> > meaning of VA_START when flippnig the VA space. Given that, this cleanup
> > looks sound to me.
> >
> > However...
> >
> > VA_START used to be the start of the TTBR1 address space, which was what
> > the "first kernel virtual address" comment was trying to say. Now it's
> > the first non-linear kernel virtual addres, which I think is very
> > confusing.
> >
> > AFAICT, that change breaks at least:
> >
> > * is_ttbr1_addr() -- now returns false for linear map addresses
> > * ptdump_check_wx() -- now skips the linear map
> > * ptdump_init() -- initialises start_address inccorrectly.
> >
> > ... so could we please find a new name for the first non-linear address,
> > e.g. PAGE_END, and leave VA_START as the first TTBR1 address?
>
> I think VA_START becomes PAGE_END and then things like is_ttbr1_addr()
> just refer to PAGE_OFFSET instead. ptdump_init() looks ok to me, but I could
> be missing something.
Yes; you're right about ptdump_init().
> Anyway, these seem to be comments on the original patches from Steve rather
> than my fixes, so please send additional fixes on top. I'll push out an
> updated branch for you to work with...
Sure, I'll post a couple of patches momentarily...
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:20 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mark.rutland, devicetree, wens, mripard, linux-kernel,
linux-sunxi, robh+dt, linux-arm-kernel
In-Reply-To: <1648748.TWHgARQioU@jernej-laptop>
On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
>
> I have Model A board which also needs ddc-en-gpios property for HDMI connector
> in order for HDMI to work correctly. Otherwise it will just use 1024x768
> resolution. Can you confirm that?
>
> Best regards,
> Jernej
>
Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
Could you send me a patch against my future v2 and I could test with/without.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Clément Péron @ 2019-08-14 13:28 UTC (permalink / raw)
To: clabbe.montjoie
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Maxime Ripard,
linux-kernel, linux-sunxi, Rob Herring, Jernej Škrabec,
linux-arm-kernel
In-Reply-To: <20190814132001.GC24324@Red>
Hi,
On Wed, 14 Aug 2019 at 15:20, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> > > This patch adds the evaluation variant of the model A of the PineH64.
> > > The model A has the same size of the pine64 and has a PCIE slot.
> > >
> > > The only devicetree difference with current pineH64, is the PHY
> > > regulator.
> >
> > I have Model A board which also needs ddc-en-gpios property for HDMI connector
> > in order for HDMI to work correctly. Otherwise it will just use 1024x768
> > resolution. Can you confirm that?
Schematics Rev A:
http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
Rev B:
http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pdf
There is a DDC_EN on REV A not on REV B
Regards,
Clément
> >
> > Best regards,
> > Jernej
> >
>
> Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
>
> Could you send me a patch against my future v2 and I could test with/without.
>
> Regards
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Red.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] arm64: memory: VA_START fixups
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
Hi all,
These patches address my concerns with the new VA_START semantic as I
spotted while reviewing Will's 52-bit VA cleanup. The first patch
corrects the newly broken usage of VA_START, and the second renames
VA_START to PAGE_END to make the new semantic clearer.
Both patches are based on the arm64 for-next/52-bit-kva branch, and I've
given a 52-bit VA configuration a build+boot test (on HW without 52-bit
VA support).
Thanks,
Mark.
Mark Rutland (2):
arm64: memory: fix flipped VA space fallout
arm64: memory: rename VA_START to PAGE_END
arch/arm64/include/asm/memory.h | 20 ++++++++++----------
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/mm/dump.c | 8 ++++----
arch/arm64/mm/fault.c | 2 +-
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 4 ++--
7 files changed, 21 insertions(+), 21 deletions(-)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] arm64: memory: fix flipped VA space fallout
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
In-Reply-To: <20190814132848.24295-1-mark.rutland@arm.com>
VA_START used to be the start of the TTBR1 address space, but now it's a
point midway though. In a couple of places we still use VA_START to get
the start of the TTBR1 address space, so let's fix these up to use
PAGE_OFFSET instead.
Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/mm/dump.c | 2 +-
arch/arm64/mm/fault.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 6ec75305828e..8e10b4ba215a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -400,7 +400,7 @@ void ptdump_check_wx(void)
.check_wx = true,
};
- walk_pgd(&st, &init_mm, VA_START);
+ walk_pgd(&st, &init_mm, PAGE_OFFSET);
note_page(&st, 0, 0, 0);
if (st.wx_pages || st.uxn_pages)
pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 75eff57bd9ef..bb4e4f3fffd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -109,7 +109,7 @@ static inline bool is_ttbr0_addr(unsigned long addr)
static inline bool is_ttbr1_addr(unsigned long addr)
{
/* TTBR1 addresses may have a tag if KASAN_SW_TAGS is in use */
- return arch_kasan_reset_tag(addr) >= VA_START;
+ return arch_kasan_reset_tag(addr) >= PAGE_OFFSET;
}
/*
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] arm64: memory: rename VA_START to PAGE_END
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
In-Reply-To: <20190814132848.24295-1-mark.rutland@arm.com>
Prior to commit:
14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
... VA_START described the start of the TTBR1 address space for a given
VA size described by VA_BITS, where all kernel mappings began.
Since that commit, VA_START described a portion midway through the
address space, where the linear map ends and other kernel mappings
begin.
To avoid confusion, let's rename VA_START to PAGE_END, making it clear
that it's not the start of the TTBR1 address space and implying that
it's related to PAGE_OFFSET. Comments and other mnemonics are updated
accordingly, along with a typo fix in the decription of VMEMMAP_SIZE.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/memory.h | 20 ++++++++++----------
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/mm/dump.c | 6 +++---
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 4 ++--
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d69c2865ae40..a713bad71db5 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -28,20 +28,20 @@
* a struct page array
*
* If we are configured with a 52-bit kernel VA then our VMEMMAP_SIZE
- * neads to cover the memory region from the beginning of the 52-bit
- * PAGE_OFFSET all the way to VA_START for 48-bit. This allows us to
+ * needs to cover the memory region from the beginning of the 52-bit
+ * PAGE_OFFSET all the way to PAGE_END for 48-bit. This allows us to
* keep a constant PAGE_OFFSET and "fallback" to using the higher end
* of the VMEMMAP where 52-bit support is not available in hardware.
*/
-#define VMEMMAP_SIZE ((_VA_START(VA_BITS_MIN) - PAGE_OFFSET) \
+#define VMEMMAP_SIZE ((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) \
>> (PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT))
/*
- * PAGE_OFFSET - the virtual address of the start of the linear map (top
- * (VA_BITS - 1))
- * KIMAGE_VADDR - the virtual address of the start of the kernel image
+ * PAGE_OFFSET - the virtual address of the start of the linear map, at the
+ * start of the TTBR1 address space.
+ * PAGE_END - the end of the linear map, where all other kernel mappings begin.
+ * KIMAGE_VADDR - the virtual address of the start of the kernel image.
* VA_BITS - the maximum number of bits for virtual addresses.
- * VA_START - the first kernel virtual address.
*/
#define VA_BITS (CONFIG_ARM64_VA_BITS)
#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
@@ -64,7 +64,7 @@
#define VA_BITS_MIN (VA_BITS)
#endif
-#define _VA_START(va) (-(UL(1) << ((va) - 1)))
+#define _PAGE_END(va) (-(UL(1) << ((va) - 1)))
#define KERNEL_START _text
#define KERNEL_END _end
@@ -87,7 +87,7 @@
#define KASAN_THREAD_SHIFT 1
#else
#define KASAN_THREAD_SHIFT 0
-#define KASAN_SHADOW_END (_VA_START(VA_BITS_MIN))
+#define KASAN_SHADOW_END (_PAGE_END(VA_BITS_MIN))
#endif /* CONFIG_KASAN */
#define MIN_THREAD_SHIFT (14 + KASAN_THREAD_SHIFT)
@@ -173,7 +173,7 @@
#ifndef __ASSEMBLY__
extern u64 vabits_actual;
-#define VA_START (_VA_START(vabits_actual))
+#define PAGE_END (_PAGE_END(vabits_actual))
#include <linux/bitops.h>
#include <linux/mmdebug.h>
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4a695b9ee0f0..979e24fadf35 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -856,8 +856,8 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
-#define kc_vaddr_to_offset(v) ((v) & ~VA_START)
-#define kc_offset_to_vaddr(o) ((o) | VA_START)
+#define kc_vaddr_to_offset(v) ((v) & ~PAGE_END)
+#define kc_offset_to_vaddr(o) ((o) | PAGE_END)
#ifdef CONFIG_ARM64_PA_BITS_52
#define phys_to_ttbr(addr) (((addr) | ((addr) >> 46)) & TTBR_BADDR_MASK_52)
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index e130db05d932..e0a7fce0e01c 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -496,7 +496,7 @@ int swsusp_arch_resume(void)
rc = -ENOMEM;
goto out;
}
- rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, VA_START);
+ rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, PAGE_END);
if (rc)
goto out;
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 8e10b4ba215a..93f9f77582ae 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -28,7 +28,7 @@
enum address_markers_idx {
PAGE_OFFSET_NR = 0,
- VA_START_NR,
+ PAGE_END_NR,
#ifdef CONFIG_KASAN
KASAN_START_NR,
#endif
@@ -36,7 +36,7 @@ enum address_markers_idx {
static struct addr_marker address_markers[] = {
{ PAGE_OFFSET, "Linear Mapping start" },
- { 0 /* VA_START */, "Linear Mapping end" },
+ { 0 /* PAGE_END */, "Linear Mapping end" },
#ifdef CONFIG_KASAN
{ 0 /* KASAN_SHADOW_START */, "Kasan shadow start" },
{ KASAN_SHADOW_END, "Kasan shadow end" },
@@ -411,7 +411,7 @@ void ptdump_check_wx(void)
static int ptdump_init(void)
{
- address_markers[VA_START_NR].start_address = VA_START;
+ address_markers[PAGE_END_NR].start_address = PAGE_END;
#ifdef CONFIG_KASAN
address_markers[KASAN_START_NR].start_address = KASAN_SHADOW_START;
#endif
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 725222271474..f87a32484ea8 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -226,7 +226,7 @@ void __init kasan_init(void)
kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
early_pfn_to_nid(virt_to_pfn(lm_alias(_text))));
- kasan_populate_early_shadow(kasan_mem_to_shadow((void *) VA_START),
+ kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
(void *)mod_shadow_start);
kasan_populate_early_shadow((void *)kimg_shadow_end,
(void *)KASAN_SHADOW_END);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0c8f7e55f859..8e4b7eaff8ce 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -399,7 +399,7 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
phys_addr_t size, pgprot_t prot)
{
- if ((virt >= VA_START) && (virt < VMALLOC_START)) {
+ if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n",
&phys, virt);
return;
@@ -426,7 +426,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
phys_addr_t size, pgprot_t prot)
{
- if ((virt >= VA_START) && (virt < VMALLOC_START)) {
+ if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n",
&phys, virt);
return;
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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