* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: David Daney @ 2017-01-18 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118142250.GB6534@bhelgaas-glaptop.roam.corp.google.com>
On 01/18/2017 06:22 AM, Bjorn Helgaas wrote:
> On Tue, Jan 17, 2017 at 03:37:10PM -0800, David Daney wrote:
[...]
>>
>>
>> Link (re)training can fail for several reasons including, but not
>> limited to:
>>
>> - Poor signal propagation through the
>> chips/packages/boards/connectors, also known as Signal Integrity
>> (SI) problmes.
>>
>> - Incorrect implementation, in hardware, of link training protocols
>> at either end of the link
>>
>> Usually, system and PCIe device vendors do a lot of testing and
>> signal analysis across a variety of configurations with the end goal
>> being that PCIe looks like a bullet-proof interconnect to the end
>> consumer.
>>
>> Unfortunatly, sometimes it doesn't work. In these cases, the
>> vendors of the devices on each end of the link tend to point fingers
>> at the link partner for being detective in some way.
>>
>> This patch:
>>
>>>
>>> The only one that comes to mind is this patch from David (CC'd) that
>>> avoids ASPM-related retrains when we know the link doesn't support ASPM:
>>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e53f9a28bee3
>>>
>>
>> Is an attempt to work around the problem from the system (host) end.
>> If the system vendor knows a priori that a defective PCIe device is
>> present in the system, the PCIe root port can be configured to
>> indicate no ASPM is supported, resulting (with the patch) in no link
>> retraining being attempted.
>>
>> To me it feels that we need a black list of devices that fail at a
>> high rate in the link retraining, that when encountered would
>> disable ASPM on the link where they reside.
>
> I should have asked you for details about the defective devices
> related to e53f9a28bee3 :) If we had included that in the changelog,
> we would have something to seed a blacklist with.
The device I saw failing I don't have access to any more, so I don't
know the PCI IDs. It was a solid-state storage device with a Xilinx
FPGA acting as the PCIe endpoint. In any event, it would only fail in
about 0.5% of system boots, it wasn't the case that it could be made to
reliably fail.
The tricky thing here is assigning the blame for failure in link
training. In the case in question we spent many months analysing the
analog properties of the bus and examining/decoding analog scope
captures of the failures before credibly assigning blame to the other
guy. Usually what happens is the device vendor accurately claims that
their device works flawlessly in conjunction with certain Intel root
ports, so the problem must be fixed in the root port of the failing
system. If you have a black list, you may be disabling ASPM in systems
where it can work without failures.
>
> There are several situations other than ASPM where link retraining is
> required per spec (rate change, error handling, etc), and I guess we'd
> have to avoid all of them. So I suppose e53f9a28bee3 avoids the most
> obvious failures, but maybe we could still see issues in those other
> cases.
>
> Bjorn
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: Tony Lindgren @ 2017-01-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b586537d-49b6-50a6-ae60-11faf25b26f9@ti.com>
* Sekhar Nori <nsekhar@ti.com> [170118 03:59]:
> Hi Tony,
>
> On Wednesday 18 January 2017 04:57 AM, Tony Lindgren wrote:
> > * B, Ravi <ravibabu@ti.com> [170117 00:15]:
> >> Hi Tony
> >>
> >>> * Ravi Babu <ravibabu@ti.com> [170113 04:41]:
> >>>> The SPL size for DRA74x platform has increased and is now more than
> >>>> 64KB. Increase QSPI SPL partition size to 256KB for DRA74x EVM.
> >>>>
> >>>> QSPI partition numbering changes because of this.
> >>
> >>> And this will break the existing partitions potentially..
> >>> See what was discussed on the list few days ago in thread "[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table".
> >>
> >>> It's best to have these left empty or as they originally were and let u-boot configure the partitions.
> >>
> >> Agree with you. For dra7xx platform the SPL size has been increased to 256KB and hence the existing QSPI SPL partition in kernel (64K size) will break when latest mainline u-boot is used.
> >> Here only SPL partition has been changed and other partition & size is NOT changed and kept intact. I feel it will not break the existing partitions for dra7xx platform.
> >
> > What about the renumbering of partitions in your patch?
>
> Thats true, partitions will get renumbered. But mtd numbering can change
> depending on probe order of devices anyway. So usespace which uses
> hardcoded mtd partition numbers is pretty fragile already, I guess.
>
> >
> > Probably just best to make the partition information empty in the
> > kernel as discussed.
>
> Given that existing dtbs already have the partition information, wont
> this be treated as a regression for someone upgrading to new kernel?
Well these "flag day" type changes are not acceptable because they are
impossible to coordinate. You can't assume people update their bootloader
on regular basis, or update both bootloader and kernel to some specific
versions.
> Going forward, is the preference that new boards shall not have
> partition information in DT?
Yes or else it will have to stay as it was originally set because
of these issues.
Regards,
Tony
^ permalink raw reply
* [PATCH 09/33] Input: sun4i-lradc-keys - Drop unnecessary call to platform_set_drvdata and other changes
From: Guenter Roeck @ 2017-01-18 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484761614-12225-1-git-send-email-linux@roeck-us.net>
There is no call to platform_get_drvdata() or dev_get_drvdata().
Drop the unnecessary call to platform_set_drvdata().
Other relevant changes:
Simplify error return
This conversion was done automatically with coccinelle using the
following semantic patches. The semantic patches and the scripts
used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches
- Replace 'if (e) return e; return 0;' with 'return e;'
- Drop platform_set_drvdata()
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/input/keyboard/sun4i-lradc-keys.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c b/drivers/input/keyboard/sun4i-lradc-keys.c
index cc8f7ddcee53..c153d956778c 100644
--- a/drivers/input/keyboard/sun4i-lradc-keys.c
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -257,12 +257,7 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
if (error)
return error;
- error = input_register_device(lradc->input);
- if (error)
- return error;
-
- platform_set_drvdata(pdev, lradc);
- return 0;
+ return input_register_device(lradc->input);
}
static const struct of_device_id sun4i_lradc_of_match[] = {
--
2.7.4
^ permalink raw reply related
* [PATCH 23/33] Input: xilinx_ps2 - Use 'dev' instead of dereferencing it and other changes
From: Guenter Roeck @ 2017-01-18 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484761614-12225-1-git-send-email-linux@roeck-us.net>
Use local variable 'dev' instead of dereferencing it several times.
This conversion was done automatically with coccinelle using the
following semantic patches. The semantic patches and the scripts
used to generate this commit log are available at
https://github.com/groeck/coccinelle-patches
- Use local variable 'struct device *dev' consistently
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/input/serio/xilinx_ps2.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
index 5223cbf94262..14c40892ed82 100644
--- a/drivers/input/serio/xilinx_ps2.c
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -243,18 +243,17 @@ static int xps2_of_probe(struct platform_device *ofdev)
unsigned int irq;
int error;
- dev_info(dev, "Device Tree Probing \'%s\'\n",
- ofdev->dev.of_node->name);
+ dev_info(dev, "Device Tree Probing \'%s\'\n", dev->of_node->name);
/* Get iospace for the device */
- error = of_address_to_resource(ofdev->dev.of_node, 0, &r_mem);
+ error = of_address_to_resource(dev->of_node, 0, &r_mem);
if (error) {
dev_err(dev, "invalid address\n");
return error;
}
/* Get IRQ for the device */
- irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
+ irq = irq_of_parse_and_map(dev->of_node, 0);
if (!irq) {
dev_err(dev, "no IRQ found\n");
return -ENODEV;
--
2.7.4
^ permalink raw reply related
* [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: Ondřej Jirman @ 2017-01-18 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118165612.zkjaj36kedg64rjw@lukather>
Dne 18.1.2017 v 17:56 Maxime Ripard napsal(a):
>>> What's your current plan to fix that? I guess the easiest (and most
>>> likely to be reusable) would be to allow for clock tables, instead of
>>> using the generic approach. We might have some other clocks (like
>>> audio or video) that would need such a precise tuning in the future
>>> too.
>>
>> My proposed solution is this for M factor (H3 specific solution):
>>
>> https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738
>
> This one is fine.
>
>> and this for P factor:
>>
>> https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a
>>
>> Perhaps it should be configurable if the P limitation is not universal
>> for all NKMP clocks. But I haven't read all the datasheets.
>
> And this is exactly what I wanted to avoid, for the reason you're
> giving :)
>
> This is some generic code, and yet you're putting a clock and SoC
> specific limit in there. You have two ways to deal with that. Either
> come up with some generic throttling mecanism to force a particular
> value above or below a given threshold, but that might be tedious to
> do, and require some significant rework.
>
> Or you can use a table, which is generic and should be relatively
> easy. I really think this is the most straightforward solution, and
> even more so since we just want to support a limited number of
> frequencies in this case.
So I would add a pointer to a table to struct ccu_nkmp and define the
table itself in ccu-sun8i-h3.c?
If struct ccu_nkmp would have non-NULL pointer to a table, it would be
used instead of the math in ccu_nkmp.c.
Sounds ok?
regards,
o.
> Maxime
>
^ permalink raw reply
* [PATCH 1/2] clk: imx7d: Add the OCOTP clock
From: Fabio Estevam @ 2017-01-18 17:53 UTC (permalink / raw)
To: linux-arm-kernel
Add the OCOTP so that this hardware block can be used.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/clk/imx/clk-imx7d.c | 1 +
include/dt-bindings/clock/imx7d-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index e7c7353..ae1d31b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -803,6 +803,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_DRAM_PHYM_ROOT_CLK] = imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130, 0);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
+ clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", "usb_hsic_post_div", base + 0x4420, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", "ahb_root_clk", base + 0x4480, 0);
clks[IMX7D_PCIE_CTRL_ROOT_CLK] = imx_clk_gate4("pcie_ctrl_root_clk", "pcie_ctrl_post_div", base + 0x4600, 0);
diff --git a/include/dt-bindings/clock/imx7d-clock.h b/include/dt-bindings/clock/imx7d-clock.h
index 1183347..a7a1a50 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -449,5 +449,6 @@
#define IMX7D_ADC_ROOT_CLK 436
#define IMX7D_CLK_ARM 437
#define IMX7D_CKIL 438
-#define IMX7D_CLK_END 439
+#define IMX7D_OCOTP_CLK 439
+#define IMX7D_CLK_END 440
#endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] clk: imx7d: Add the IPG root clock
From: Fabio Estevam @ 2017-01-18 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484762037-10737-1-git-send-email-fabio.estevam@nxp.com>
Add an entry for the IMX7D_IPG_ROOT clock.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
drivers/clk/imx/clk-imx7d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index ae1d31b..1705f44 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -788,7 +788,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_WRCLK_ROOT_DIV] = imx_clk_divider2("wrclk_post_div", "wrclk_pre_div", base + 0xbd00, 0, 6);
clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div", "clko1_pre_div", base + 0xbd80, 0, 6);
clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div", "clko2_pre_div", base + 0xbe00, 0, 6);
-
+ clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk", "ahb_root_clk", base + 0x9080, 0, 2);
clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk", "arm_a7_div", base + 0x4000, 0);
clks[IMX7D_ARM_M4_ROOT_CLK] = imx_clk_gate4("arm_m4_root_clk", "arm_m4_div", base + 0x4010, 0);
clks[IMX7D_ARM_M0_ROOT_CLK] = imx_clk_gate4("arm_m0_root_clk", "arm_m0_div", base + 0x4020, 0);
--
2.7.4
^ permalink raw reply related
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Russell King - ARM Linux @ 2017-01-18 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1137f732-f31e-8162-af8f-6a7f577a9648@caviumnetworks.com>
On Wed, Jan 18, 2017 at 09:36:55AM -0800, David Daney wrote:
> On 01/18/2017 06:22 AM, Bjorn Helgaas wrote:
> The tricky thing here is assigning the blame for failure in link training.
> In the case in question we spent many months analysing the analog properties
> of the bus and examining/decoding analog scope captures of the failures
> before credibly assigning blame to the other guy. Usually what happens is
> the device vendor accurately claims that their device works flawlessly in
> conjunction with certain Intel root ports, so the problem must be fixed in
> the root port of the failing system. If you have a black list, you may be
> disabling ASPM in systems where it can work without failures.
So what we need is not a table of just devices, but a combination of
devices... iow, "when root A and endpoint B are combined, retrains
need to be avoided."
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Leif Lindholm @ 2017-01-18 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115124254.GF25883@bivouac.eciton.net>
On 15 January 2017 at 12:42, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Fri, Jan 13, 2017 at 11:48:01AM +0000, Will Deacon wrote:
>> On Fri, Jan 13, 2017 at 11:37:34AM +0000, Leif Lindholm wrote:
>> > /dev/mem is the opposite of what an operating system is for.
>> > Additionally, on arm* it opens up for denial-of-service attacks from
>> > userspace. So leave it disabled by default, requiring people who need
>> > it to enable it explicitly.
>>
>> I really like the idea, but are we sure that nothing common breaks without
>> this? For example, does Debian still boot nicely with this patch applied?
>
> Getting distros to not have to shop around for config fragments in
> order to be able to a stable system is one of my main purposes of this
> patch.
>
> Since Debian just published a 4.9 kernel, I gave that a spin (both DT
> and ACPI). No issues.
Will, any comments?
/
Leif
>> Just trying to get a feel for how much userspace this has seen (particularly
>> on ACPI-based systems, which I seem to remember like poking about in here).
>
> There are various tools that let you figure out various things about
> the system (a bit like running dtc on a dump of the active
> device-tree), but nothing actually used for booting a system (much
> like dtc).
>
> /dev/mem has been used for things like dmidecode and acpidump in the
> past, but we fixed those tools back in 2015 to use /sys interfaces
> instead of blindly groping around and hoping for the best.
>
> Stretch version of dmidecode operates as expected on both DT and ACPI
> boot, and acpidump does in the ACPI case (no tables in /sys otherwise).
>
> There may be other tools that will also break if not implementing
> support for access via /sys, but none critical for system operation
> (and currently a denial-of-service waiting to happen anyway).
>
> Systemd will try to access /dev/mem to extract boot timestamp stuff,
> but handles a failure gracefully (i.e. not even a warning message).
^ permalink raw reply
* [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Andy Shevchenko @ 2017-01-18 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484757988-23739-3-git-send-email-agustinv@codeaurora.org>
On Wed, Jan 18, 2017 at 6:46 PM, Agustin Vega-Frias
<agustinv@codeaurora.org> wrote:
> ACPI extended IRQ resources may contain a ResourceSource to specify
> an alternate interrupt controller. Introduce acpi_irq_get and use it
> to implement ResourceSource/IRQ domain mapping.
>
> The new API is similar to of_irq_get and allows re-initialization
> of a platform resource from the ACPI extended IRQ resource, and
> provides proper behavior for probe deferral when the domain is not
> yet present when called.
>
Care to use -M -C when prepare this patch?
> drivers/acpi/gsi.c | 98 -----------------
> drivers/acpi/irq.c | 282 ++++++++++++++++++++++++++++++++++++++++++++++++
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 6/9] kvm: arm/arm64: Add host pmu to support VM introspection
From: Mark Rutland @ 2017-01-18 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f5smjg1.fsf@e105922-lin.cambridge.arm.com>
On Wed, Jan 18, 2017 at 04:17:18PM +0000, Punit Agrawal wrote:
> Mark Rutland <mark.rutland@arm.com> writes:
>
> > On Wed, Jan 18, 2017 at 02:51:31PM +0000, Punit Agrawal wrote:
> >> I should've clarified in my reply that I wasn't looking to support the
> >> third instance from Mark's examples above - "monitor all vCPUs on a
> >> pCPU". I think it'll be quite expensive to figure out which threads from
> >> a given pool are vCPUs.
> >
> > I'm not sure I follow why you would need to do that?
> >
> > In that case, we'd open a CPU-bound perf event for the pCPU, which would
> > get installed in the CPU context immediately. It would be present for
> > all tasks.
> >
> > Given it's present for all tasks, we don't need to figure out which
> > happen to have vCPUs. The !vCPU tasks simply shouldn't trigger events.
> >
> > Am I missing something?
>
> When enabling a CPU-bound event for pCPU, we'd have to enable trapping
> of TLB operations for the vCPUs running on pCPU. Have a look at Patch
> 7/9.
>
> Also, we'd have to enable/disable trapping when tasks are migrated
> between pCPUs.
Ah, so we can't configure the trap and leave it active, since it'll
affect the host.
We could have a per-cpu flag, and a hook into vcpu_run, but that's also
gnarly.
I'll have a think.
> So far I've assumed that a VM pid is immutable. If that doesn't hold
> then we need to think of another mechanism to refer to a VM from
> userspace.
Even if we can't migrate the VM between processes (i.e. it's immutable),
it's still not unique within a process, so I'm fairly sure we need
another mechanism (even if we get away with the common case today).
Thanks,
Mark.
^ permalink raw reply
* [PATCH] clk: meson-gxbb: Export HDMI clocks
From: Kevin Hilman @ 2017-01-18 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117183441.GU17126@codeaurora.org>
Stephen Boyd <sboyd@codeaurora.org> writes:
> On 01/17, Neil Armstrong wrote:
>> Export HDMI clock from internal to dt-bindings.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
>
> I think we decided this would go with the dts changes if more
> needed to be exposed.
Ah, that's right. I'll queue it up in the amlogic dt branch with your
ack.
Thanks,
Kevin
^ permalink raw reply
* [PATCH] ARM: pxa: include linux/leds.h
From: Robert Jarzmik @ 2017-01-18 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118164936.3832865-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> When the header is not included implicitly, we get a build failure:
>
> arch/arm/mach-pxa/idp.c:205:22: error: field 'cdev' has incomplete type
> struct led_classdev cdev;
>
> This adds an explicit #include.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Sure, pushed into pxa/for-next, I hope it's not troublesome enough to include it
in the 4.10 cycle pxa fixes which is ... empty so far.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v3 09/13] sata: ahci: export ahci_do_hardreset() locally
From: Tejun Heo @ 2017-01-18 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484745601-4769-10-git-send-email-bgolaszewski@baylibre.com>
Hello, Bartosz.
On Wed, Jan 18, 2017 at 02:19:57PM +0100, Bartosz Golaszewski wrote:
> We need a way to retrieve the information about the online state of
> the link in the ahci-da850 driver.
>
> Create a new function: ahci_do_hardreset() which is called from
> ahci_hardreset() for backwards compatibility, but has an additional
> argument: 'online' - which can be used to check if the link is online
> after this function returns.
Please just add @online to ahci_hardreset() and update the callers.
Other than that, the sata changes look good to me.
Thanks.
--
tejun
^ permalink raw reply
* [GIT PULL v2] arm64: dts: juno: updates for v4.11
From: Sudeep Holla @ 2017-01-18 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbfa1905-d937-7d02-7bbb-5f1a127896cf@arm.com>
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
v1->v2:
- Fixed device node names for coresight components as suggested by Olof
- Removed nested dtsi inclusions(again Olof's suggestions - Thanks)
- Added some minor cleanup and updates from Robin
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-4.11
for you to fetch changes up to 1492a864364ed46be2abeaaaf3b1a248f19e6644:
arm64: dts: juno: remove motherboard USB node (2017-01-18 14:01:20 +0000)
----------------------------------------------------------------
ARMv8 Vexpress/Juno DT updates for v4.11
1. Addition of Coresight support on Juno R1 and R2 variants
2. Addition of STM(System Trace Macrocell) support on all Juno variants
3. Removed incorrect nesting of dtsi files
4. Removed untested USB hub only available on initial Juno R0 motherboard
5. Added ETR SMMU power domain and dma-ranges property
----------------------------------------------------------------
Mike Leach (2):
arm64: dts: juno: add CoreSight support for Juno r1/r2 variants
arm64: dts: juno: add missing CoreSight STM component
Robin Murphy (3):
arm64: dts: juno: add dma-ranges property
arm64: dts: juno: add ETR SMMU power domain
arm64: dts: juno: remove motherboard USB node
Sudeep Holla (2):
arm64: dts: juno: remove dtsi nesting inside tree structure
arm64: dts: juno: refactor CoreSight support on Juno r0
arch/arm64/boot/dts/arm/juno-base.dtsi | 43 +++++++----
arch/arm64/boot/dts/arm/juno-clocks.dtsi | 3 +-
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 100 ++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 7 --
arch/arm64/boot/dts/arm/juno-r1.dts | 16 ++++-
arch/arm64/boot/dts/arm/juno-r2.dts | 16 ++++-
arch/arm64/boot/dts/arm/juno.dts | 27 ++++++-
7 files changed, 186 insertions(+), 26 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
^ permalink raw reply
* [PATCH v9 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-18 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn0ea2j_oUijOdHgiL3JU4TM0HZoL+-ggzjpPL2eA7tDCw@mail.gmail.com>
Hello Cedric,
On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
> >> + * In standard mode, the maximum allowed SCL rise time is 1000 ns.
> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> + * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
> >
> > * programmed with 0x9.
> > (1000 ns / 125 ns = 8)
> >
> >> + * So, for I2C standard mode TRISE = FREQ[5:0] + 1
> >> + *
> >> + * In fast mode, the maximum allowed SCL rise time is 300 ns.
> >> + * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
> >> + * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
> >> + * programmed with 03h.(300 ns / 125 ns = 2 + 1)
> >
> > as above s/03h/0x3/;
>
> ok
>
> > s/.(/. (/;
> ok
>
> > s/+ 1//;
> This formula is use to understand how we find the result 0x3
> So, 0x3 => 300 ns / 125ns = 2 + 1
Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
irritating at best.
> >> + * So, for I2C fast mode TRISE = FREQ[5:0] * 300 / 1000 + 1
> >> + */
> >> + if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
> >> + trise = freq + 1;
> >> + else
> >> + trise = freq * 300 / 1000 + 1;
> >
> > I'd use
> >
> > * 3 / 10
> >
> > without downside and lesser chance to overflow.
>
> There is no chance of overflow as the max freq value allowed is 46
ok
> >> + /*
> >> + * In fast mode, we compute CCR with duty = 0 as with low
> >> + * frequencies we are not able to reach 400 kHz.
> >> + * In that case:
> >> + * t_scl_high = CCR * I2C parent clk period
> >> + * t_scl_low = 2 * CCR * I2C parent clk period
> >> + * So, CCR = I2C parent rate / (400 kHz * 3)
> >> + *
> >> + * For example with parent rate = 6 MHz:
> >> + * CCR = 6000000 / (400000 * 3) = 5
> >> + * t_scl_high = 5 * (1 / 6000000) = 833 ns > 600 ns
> >> + * t_scl_low = 2 * 5 * (1 / 6000000) = 1667 ns > 1300 ns
> >> + * t_scl_high + t_scl_low = 2500 ns so 400 kHz is reached
> >> + */
> >
> > Huh, that's surprising. So you don't use DUTY any more. I found two
> > hints in the manual that contradict here:
>
> Yes with the above formula we could use duty = 0 by default
>
> >
> > f_{PCLK1} must be at least 2 MHz to achieve Sm mode I2C frequencies
>
> STM32F4_I2C_MIN_STANDARD_FREQ = 2
>
> > It must be at least 4 MHz to achieve Fm mode I2C frequencies.
>
> STM32F4_I2C_MIN_FAST_FREQ = 6
>
> > It must be a multiple of 10MHz to reach the 400 kHz maximum I2C Fm mode clock.
>
> If we use this rule only 3 values are allowed 10 Mhz, 20 Mhz, 30 Mhz and 40 Mhz.
> It is very restrictive.
> So I don't take it into account in order to have more frequencies even
> if 400 Khz is not reached.
> Indeed, in many cases we are very close to 400 Khz.
> For example, the default I2C parent clock in my board is 45 Mhz
> I reach 395 kHz in theory and 390 kHz by testing.
> I am in Fast mode but not with the max freq but very close.
fine
> > and
> >
> > [...]
> > If DUTY = 1: (to reach 400 kHz)
> >
> > Strange.
> >
> >> + val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
> >
> > the manual reads:
> >
> > The minimum allowed value is 0x04, except in FAST DUTY mode
> > where the minimum allowed value is 0x01
> >
> > You don't check for that, right?
>
> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
> as described in the comment.
> So I don't need to check that again as it is already done by checking
> parent frequency.
That would then go into a comment.
> > CCR is 11 bits wide. A comment confirming that this cannot overflow
> > would be nice.
>
> Again there is no chance of overflow thanks to parent frequency check
Right, this time I saw this myself, so I requested a comment stating
this fact.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Initializing MAC address at run-time
From: Uwe Kleine-König @ 2017-01-18 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e083ed68-0e8e-380e-23bd-5ad387c88575@free.fr>
Hello,
On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote:
> When my system boots up, eth0 is given a seemingly random MAC address.
>
> [ 0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38
> [ 0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4
>
>
> The DT node for eth0 is:
>
> eth0: ethernet at 26000 {
> compatible = "sigma,smp8734-ethernet";
> reg = <0x26000 0x800>;
> interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clkgen SYS_CLK>;
> };
>
> Documentation/devicetree/bindings/net/ethernet.txt mentions
> - local-mac-address: array of 6 bytes, specifies the MAC address that was
> assigned to the network device;
>
> And indeed, if I define this property, eth0 ends up with the MAC address
> I specify in the device tree. But of course, I don't want all my boards
> to share the same MAC address. Every interface has a unique MAC address.
>
> In fact, the boot loader (not Uboot, a custom non-DT boot loader) stores
> the MAC address somewhere in MMIO space, in some weird custom format.
Where does your machine get the dtb from? You write it to the boot
medium at a certain point of time I assume. So AFAICT you have the
following options (in no particular order):
a) Describe in the dtb how to find out how the MAC address is stored
(already pointed out Mark and Robin)
b) Make your bootloader dt aware and let it provide the
local-mac-address property.
c) Adapt the dtb before it is written to the boot medium.
d) Let the bootloader configure the device and teach the driver to pick
up the mac from the device's address space.
e) Accept that the mac address is random during development, and make
Userspace configure the MAC address, which is early enough for
production use.
Not sure d) is considered ok today, but some drivers have this feature.
I'd say b) is the best choice.
> I need to do something similar with the NAND partitions. The boot loader
> stores the partition offsets somewhere, and I need to pass this info
> to the NAND framework, so I assumed that inserting the corresponding
> properties at run-time was the correct way to do it.
The list of options here is similar to the list above. d) doesn't work,
but instead you can pass the partitioning on the kernel commandline.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Agustin Vega-Frias @ 2017-01-18 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VcLL9zvRXGCy2ynjhYFUgbYwJvLpCiUxjtsKmXjVFHmKA@mail.gmail.com>
Hi Andy,
On 2017-01-18 13:00, Andy Shevchenko wrote:
> On Wed, Jan 18, 2017 at 6:46 PM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
>> ACPI extended IRQ resources may contain a ResourceSource to specify
>> an alternate interrupt controller. Introduce acpi_irq_get and use it
>> to implement ResourceSource/IRQ domain mapping.
>>
>> The new API is similar to of_irq_get and allows re-initialization
>> of a platform resource from the ACPI extended IRQ resource, and
>> provides proper behavior for probe deferral when the domain is not
>> yet present when called.
>>
>
> Care to use -M -C when prepare this patch?
>
I did use it, but the similarity index was below the default threshold.
I'll send in a new version of this patch with this fixed.
Thanks,
Agustin
>> drivers/acpi/gsi.c | 98 -----------------
>> drivers/acpi/irq.c | 282
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>
> --
> With Best Regards,
> Andy Shevchenko
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Stefano Stabellini @ 2017-01-18 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587F518802000078001312AB@prv-mh.provo.novell.com>
On Wed, 18 Jan 2017, Jan Beulich wrote:
> >>> On 17.01.17 at 23:20, <sstabellini@kernel.org> wrote:
> > b) Otherwise, we could write an alternative implementation of ioremap
> > on arm64. The Xen specific ioremap would request a stage-2 mapping
> > first, then create the stage-1 mapping as usual. However, this means
> > issuing an hypercall for every ioremap call.
>
> +1 for this being the best choice among the ones listed. In fact
> this may also be a reasonable approach for PVHv2, unless facing
> resistance by the x86 maintainers.
Adding more context so that the Linux folks can follow. PVHv2 is a new
Xen x86 virtual machine type with very similar requirements as Xen ARM
virtual machines.
In other words, PVHv2 has the same problems described here, except that
it's x86, rather than arm64.
With my ARM maintainer hat on, I described the issue for Xen on ARM, but
it pretty much applies to x86 as well.
^ permalink raw reply
* [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Stefano Stabellini @ 2017-01-18 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118110243.ctqpperggim5k7dw@dhcp-3-221.uk.xensource.com>
On Wed, 18 Jan 2017, Roger Pau Monn? wrote:
> On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> > a) One option is to provide a Xen specific implementation of
> > acpi_os_ioremap in Linux. I think this is the cleanest approach, but
> > unfortunately, it doesn't cover cases where ioremap is used directly. (2)
> > is one of such cases, see
> > arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
> > drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
> > see drivers/acpi/apei/bert.c:bert_init.
>
> This is basically the same as b) from Xen's PoV, the only difference is where
> you would call the hypercall from Dom0 to establish stage-2 mappings.
Right, but it is important from the Linux point of view, this is why I
am asking the Linux maintainers.
> > b) Otherwise, we could write an alternative implementation of ioremap
> > on arm64. The Xen specific ioremap would request a stage-2 mapping
> > first, then create the stage-1 mapping as usual. However, this means
> > issuing an hypercall for every ioremap call.
>
> This seems fine to me, and at present is the only way to get something working.
> As you said not being able to discover OperationRegions from Xen means that
> there's a chance some MMIO might not be added to the stage-2 mappings.
>
> Then what's the initial memory map state when Dom0 is booted? There are no MMIO
> mappings at all, and Dom0 must request mappings for everything?
Yes
> What happens to ACPI tables crafted for Dom0 that reside in RAM? That would
> apply to the STAO and to the other tables that are crafted for Dom0 at build
> time. Should Dom0 also request stage-2 mappings for them, and Xen simply ignore
> those calls?
The ACPI (and UEFI) tables are mapped by Xen
> > c) Finally, a third option is to create the stage-2 mappings seamlessly
> > in Xen upon Dom0 memory faults. Keeping in mind that SMMU and guest
> > pagetables are shared in the Xen hypervisor, this approach does not work
> > if one of the pages that need a stage-2 mapping is used as DMA target
> > before Dom0 accesses it. No SMMU mappings would be available for the
> > page yet, so the DMA transaction would fail. After Dom0 touches the
> > page, the DMA transaction would succeed. I don't know how likely is this
> > scenario to happen, but it seems fragile to rely on it.
>
> Don't you get faults on SMMU failures? But I guess those are not synchronous,
> so there's no way you can add mappings on fault, like you can for processor
> accesses.
Right
^ permalink raw reply
* linux-next: manual merge of the amlogic tree with the arm-soc tree
From: Kevin Hilman @ 2017-01-18 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118095531.37f33df0@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the amlogic tree got a conflict in:
>
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>
> between commit:
>
> f7bcd4b6f698 ("ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS")
>
> from the arm-soc tree and commit:
>
> 47961f1353b8 ("ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx")
>
> from the amlogic tree.
The latter has been dropped from the amlogic pending some ongoing
discussion, but I forgot to push an updated for-next. That's remedied
now.
Kevin
^ permalink raw reply
* [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Julien Grall @ 2017-01-18 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1701181058110.10192@sstabellini-ThinkPad-X260>
Hi,
On 18/01/17 19:05, Stefano Stabellini wrote:
> On Wed, 18 Jan 2017, Roger Pau Monn? wrote:
>> On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
>>> a) One option is to provide a Xen specific implementation of
>>> acpi_os_ioremap in Linux. I think this is the cleanest approach, but
>>> unfortunately, it doesn't cover cases where ioremap is used directly. (2)
>>> is one of such cases, see
>>> arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
>>> drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
>>> see drivers/acpi/apei/bert.c:bert_init.
>>
>> This is basically the same as b) from Xen's PoV, the only difference is where
>> you would call the hypercall from Dom0 to establish stage-2 mappings.
>
> Right, but it is important from the Linux point of view, this is why I
> am asking the Linux maintainers.
>
>
>>> b) Otherwise, we could write an alternative implementation of ioremap
>>> on arm64. The Xen specific ioremap would request a stage-2 mapping
>>> first, then create the stage-1 mapping as usual. However, this means
>>> issuing an hypercall for every ioremap call.
>>
>> This seems fine to me, and at present is the only way to get something working.
>> As you said not being able to discover OperationRegions from Xen means that
>> there's a chance some MMIO might not be added to the stage-2 mappings.
>>
>> Then what's the initial memory map state when Dom0 is booted? There are no MMIO
>> mappings at all, and Dom0 must request mappings for everything?
>
> Yes
To give more context here, the UEFI memory map does not report all the
MMIO regions. So there is no possibility to map MMIO at boot.
>
>
>> What happens to ACPI tables crafted for Dom0 that reside in RAM? That would
>> apply to the STAO and to the other tables that are crafted for Dom0 at build
>> time. Should Dom0 also request stage-2 mappings for them, and Xen simply ignore
>> those calls?
>
> The ACPI (and UEFI) tables are mapped by Xen
I think Royger's point is DOM0 cannot tell whether a region has been
mapped by Xen or not.
The function ioremap will be used to map anything (it is the leaf of all
mapping functions), and will call Xen no matter the address passed. It
could be a RAM region, HW device region, emulated device region.
For the RAM and emulated device region we don't want Xen to modify the
mapping. Note that the current hypercall does not report an error back
(see [1]) but I think it is a different error.
Also, I think we would need some work in Xen because, from my
understanding of acpi_iomem_deny_access, DOM0 would be able to map the
RAM through this hypercall. So it would mess-up with the page table even
if it should not.
Cheers,
--
Julien Grall
^ permalink raw reply
* [PATCH 23/33] Input: xilinx_ps2 - Use 'dev' instead of dereferencing it and other changes
From: Dmitry Torokhov @ 2017-01-18 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484761614-12225-24-git-send-email-linux@roeck-us.net>
On Wed, Jan 18, 2017 at 09:46:44AM -0800, Guenter Roeck wrote:
> Use local variable 'dev' instead of dereferencing it several times.
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use local variable 'struct device *dev' consistently
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Applied, thank you.
> ---
> drivers/input/serio/xilinx_ps2.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
> index 5223cbf94262..14c40892ed82 100644
> --- a/drivers/input/serio/xilinx_ps2.c
> +++ b/drivers/input/serio/xilinx_ps2.c
> @@ -243,18 +243,17 @@ static int xps2_of_probe(struct platform_device *ofdev)
> unsigned int irq;
> int error;
>
> - dev_info(dev, "Device Tree Probing \'%s\'\n",
> - ofdev->dev.of_node->name);
> + dev_info(dev, "Device Tree Probing \'%s\'\n", dev->of_node->name);
>
> /* Get iospace for the device */
> - error = of_address_to_resource(ofdev->dev.of_node, 0, &r_mem);
> + error = of_address_to_resource(dev->of_node, 0, &r_mem);
> if (error) {
> dev_err(dev, "invalid address\n");
> return error;
> }
>
> /* Get IRQ for the device */
> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> + irq = irq_of_parse_and_map(dev->of_node, 0);
> if (!irq) {
> dev_err(dev, "no IRQ found\n");
> return -ENODEV;
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* [PATCH] ARM: mm: add testcases for RODATA
From: Laura Abbott @ 2017-01-18 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118135310.GA4733@pjb1027-Latitude-E5410>
On 01/18/2017 05:53 AM, Jinbum Park wrote:
> This patch adds testcases for the CONFIG_DEBUG_RODATA option.
> It's similar to x86's testcases.
> It tests read-only mapped data and page-size aligned rodata section.
>
> Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
> ---
> arch/arm/Kconfig.debug | 5 +++
> arch/arm/include/asm/cacheflush.h | 10 +++++
> arch/arm/mm/Makefile | 1 +
> arch/arm/mm/init.c | 6 +++
> arch/arm/mm/test_rodata.c | 80 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 102 insertions(+)
> create mode 100644 arch/arm/mm/test_rodata.c
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index d83f7c3..511e5e1 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1749,6 +1749,11 @@ config DEBUG_SET_MODULE_RONX
> against certain classes of kernel exploits.
> If in doubt, say "N".
>
> +config DEBUG_RODATA_TEST
> + bool "Testcase for the marking rodata read-only"
> + ---help---
> + This option enables a testcase for the setting rodata read-only.
> +
> source "drivers/hwtracing/coresight/Kconfig"
>
> endmenu
> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> index bdd283b..741e2e8 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -498,6 +498,16 @@ static inline void set_kernel_text_rw(void) { }
> static inline void set_kernel_text_ro(void) { }
> #endif
>
> +#ifdef CONFIG_DEBUG_RODATA_TEST
> +extern const int rodata_test_data;
> +int rodata_test(void);
> +#else
> +static inline int rodata_test(void)
> +{
> + return 0;
> +}
> +#endif
> +
> void flush_uprobe_xol_access(struct page *page, unsigned long uaddr,
> void *kaddr, unsigned long len);
>
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index b3dea80..dbb76ff 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -15,6 +15,7 @@ endif
> obj-$(CONFIG_ARM_PTDUMP) += dump.o
> obj-$(CONFIG_MODULES) += proc-syms.o
> obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> +obj-$(CONFIG_DEBUG_RODATA_TEST) += test_rodata.o
>
> obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
> obj-$(CONFIG_HIGHMEM) += highmem.o
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 4127f57..3c15f3b 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -716,6 +716,7 @@ void fix_kernmem_perms(void)
> int __mark_rodata_ro(void *unused)
> {
> update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
> + rodata_test();
We don't do anything with this return value, should we at least
spit out a warning?
> return 0;
> }
>
> @@ -740,6 +741,11 @@ void set_kernel_text_ro(void)
> static inline void fix_kernmem_perms(void) { }
> #endif /* CONFIG_DEBUG_RODATA */
>
> +#ifdef CONFIG_DEBUG_RODATA_TEST
> +const int rodata_test_data = 0xC3;
This isn't accessed outside of test_rodata.c, it can just
be moved there.
> +EXPORT_SYMBOL_GPL(rodata_test_data);
> +#endif
> +
> void free_tcmmem(void)
> {
> #ifdef CONFIG_HAVE_TCM
> diff --git a/arch/arm/mm/test_rodata.c b/arch/arm/mm/test_rodata.c
> new file mode 100644
> index 0000000..133d092
> --- /dev/null
> +++ b/arch/arm/mm/test_rodata.c
> @@ -0,0 +1,79 @@
> +/*
> + * test_rodata.c: functional test for mark_rodata_ro function
> + *
> + * (C) Copyright 2017 Jinbum Park <jinb.park7@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2
> + * of the License.
> + */
> +#include <asm/cacheflush.h>
> +#include <asm/sections.h>
> +
> +int rodata_test(void)
> +{
> + unsigned long result;
> + unsigned long start, end;
> +
> + /* test 1: read the value */
> + /* If this test fails, some previous testrun has clobbered the state */
> +
> + if (!rodata_test_data) {
> + pr_err("rodata_test: test 1 fails (start data)\n");
> + return -ENODEV;
> + }
> +
> + /* test 2: write to the variable; this should fault */
> + /*
> + * If this test fails, we managed to overwrite the data
> + *
> + * This is written in assembly to be able to catch the
> + * exception that is supposed to happen in the correct
> + * case
> + */
> +
> + result = 1;
> + asm volatile(
> + "0: str %[zero], [%[rodata_test]]\n"
> + " mov %[rslt], %[zero]\n"
> + "1:\n"
> + ".pushsection .text.fixup,\"ax\"\n"
> + ".align 2\n"
> + "2:\n"
> + "b 1b\n"
> + ".popsection\n"
> + ".pushsection __ex_table,\"a\"\n"
> + ".align 3\n"
> + ".long 0b, 2b\n"
> + ".popsection\n"
> + : [rslt] "=r" (result)
> + : [zero] "r" (0UL), [rodata_test] "r" (&rodata_test_data)
> + );
> +
> + if (!result) {
> + pr_err("rodata_test: test data was not read only\n");
> + return -ENODEV;
> + }
> +
> + /* test 3: check the value hasn't changed */
> + /* If this test fails, we managed to overwrite the data */
> + if (!rodata_test_data) {
> + pr_err("rodata_test: Test 3 fails (end data)\n");
> + return -ENODEV;
> + }
I'm confused why we are checking this again when we have the result
check above. Is there a case where we would still have result = 1
but rodata_test_data overwritten?
> +
> + /* test 4: check if the rodata section is 4Kb aligned */
> + start = (unsigned long)__start_rodata;
> + end = (unsigned long)__end_rodata;
> + if (start & (PAGE_SIZE - 1)) {
> + pr_err("rodata_test: .rodata is not 4k aligned\n");
> + return -ENODEV;
> + }
> + if (end & (PAGE_SIZE - 1)) {
> + pr_err("rodata_test: .rodata end is not 4k aligned\n");
> + return -ENODEV;
> + }
Why does this need to be page aligned (yes, I know why but this
test case does not make it clear)
Better yet, this should be a build time assertion not a runtime
one.
> +
> + return 0;
> +}
>
As Mark mentioned, this is possibly redundant with LKDTM. It
would be good to explain what benefit this is bringing in addition
to LKDTM.
Thanks,
Laura
^ permalink raw reply
* [PATCH] ahci: qoriq: added ls2088a platforms support
From: Tejun Heo @ 2017-01-18 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484633521-10938-1-git-send-email-yuantian.tang@nxp.com>
On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Ls2088a is new introduced arm-based soc with sata support with
> following features:
> 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
> specification
> 2. Contains a high-speed descriptor-based DMA controller
> 3. Supports the following:
> a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
> (second-generation SATA), and 6 Gb/s (third-generation SATA)
> b. FIS-based switching
> c. Native command queuing (NCQ) commands
> d. Port multiplier operation
> e. Asynchronous notification
> f. SATA BIST mode
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Applied to libata/for-4.11.
Thanks.
--
tejun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox