* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Will Deacon @ 2016-10-19 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> We now delay installing our per-bus iommu_ops until we know an SMMU has
> successfully probed, as they don't serve much purpose beforehand, and
> doing so also avoids fights between multiple IOMMU drivers in a single
> kernel. However, the upshot of passing the return value of bus_set_iommu()
> back from our probe function is that if there happens to be more than
> one SMMUv3 device in a system, the second and subsequent probes will
> wind up returning -EBUSY to the driver core and getting torn down again.
>
> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> 1. The bus already has iommu_ops installed
> 2. One of the add_device callbacks from the initial notifier failed
> 3. Allocating or installing the notifier itself failed
>
> The first two are down to devices other than the SMMU in question, so
> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> indicative of the kind of catastrophic system failure which isn't going
> to get much further anyway. Consequently, there is little harm in
> ignoring the return value either way.
>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3cd540..74fbef384deb 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> #ifdef CONFIG_PCI
> pci_request_acs();
> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> #endif
> #ifdef CONFIG_ARM_AMBA
> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + return 0;
In which case, we should probably add an iommu_present check, like we
have for the v2 driver.
Will
^ permalink raw reply
* [PATCH] ARM: mm: add ARM_L1_CACHE_SHIFT_7 for UniPhier outer cache
From: Masahiro Yamada @ 2016-10-19 12:39 UTC (permalink / raw)
To: linux-arm-kernel
The UniPhier outer cache (arch/arm/mm/cache-uniphier.c) has 128 byte
line length and its tags are also managed per 128 byte line. This
is very unfortunate, but the current 64 byte alignment for kmalloc()
causes sharing problems on DMA if used with this outer cache.
This commit adds ARM_L1_CACHE_SHIFT_7 to increase the DMA minimum
alignment to 128 byte if CACHE_UNIPHIER is enabled. There are
several drivers that assume aligning to L1_CACHE_BYTES will be DMA
safe, so this commit also changes the L1_CACHE_BYTES for safety.
Having said that, I hesitate to align all the other SoCs in Multi
platform to the UniPhier's requirement. So, I am disabling the
CONFIG_CACHE_UNIPHIER by default, so that multi_v7_defconfig will
still with CONFIG_ARM_L1_CACHE_SHIFT=6. With this, UniPhier SoCs
become a bit slower, but it is much better than system crash.
If desired, the outer-cache can be enabled by the merge_config or
something.
Note:
The UniPhier PH1-Pro5 SoC is equipped also with L3 cache with 256 byte
line size but its tags are managed per 128 byte sub-line.
So, ARM_L1_CACHE_SHIFT_7 should be fine for all the UniPhier SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
I threw a question in January this year:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/400289.html
After a long interval, I came back to this topic.
arch/arm/mm/Kconfig | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c1799dd..f68e8ec 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -991,7 +991,7 @@ config CACHE_TAUROS2
config CACHE_UNIPHIER
bool "Enable the UniPhier outer cache controller"
depends on ARCH_UNIPHIER
- default y
+ select ARM_L1_CACHE_SHIFT_7
select OUTER_CACHE
select OUTER_CACHE_SYNC
help
@@ -1012,8 +1012,14 @@ config ARM_L1_CACHE_SHIFT_6
help
Setting ARM L1 cache line size to 64 Bytes.
+config ARM_L1_CACHE_SHIFT_7
+ bool
+ help
+ Setting ARM L1 cache line size to 128 Bytes.
+
config ARM_L1_CACHE_SHIFT
int
+ default 7 if ARM_L1_CACHE_SHIFT_7
default 6 if ARM_L1_CACHE_SHIFT_6
default 5
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/9] of: Add vendor prefix for Netron DY
From: Thierry Reding @ 2016-10-19 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160906144620.6322-6-maxime.ripard@free-electrons.com>
On Tue, Sep 06, 2016 at 04:46:16PM +0200, Maxime Ripard wrote:
> Netron DY is a brand of LCD panels found on SBCs and tablets.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Hi Rob,
care to give this your Acked-by?
Thanks,
Thierry
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 1992aa97d45a..9c1ab3c1132b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -176,6 +176,7 @@ nec NEC LCD Technologies, Ltd.
> neonode Neonode Inc.
> netgear NETGEAR
> netlogic Broadcom Corporation (formerly NetLogic Microsystems)
> +netron-dy Netron DY
> netxeon Shenzhen Netxeon Technology CO., LTD
> newhaven Newhaven Display International
> nintendo Nintendo
> --
> 2.9.3
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/8e2680c2/attachment-0001.sig>
^ permalink raw reply
* [PATCH] mmc: sunxi: Prevent against null dereference for vmmc
From: Maxime Ripard @ 2016-10-19 12:36 UTC (permalink / raw)
To: linux-arm-kernel
VMMC is an optional regulator, which means that mmc_regulator_get_supply
will only return an error in case of a deferred probe, but not when the
regulator is not set in the DT.
However, the sunxi driver assumes that VMMC is always there, and doesn't
check the value of the regulator pointer before using it, which obviously
leads to a (close to) null pointer dereference.
Add proper checks to prevent that.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index c0a5c676d0e8..45a051e7d650 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -822,10 +822,16 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
break;
case MMC_POWER_UP:
- host->ferror = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
- ios->vdd);
- if (host->ferror)
- return;
+ if (!IS_ERR(mmc->supply.vmmc)) {
+ host->ferror = mmc_regulator_set_ocr(mmc,
+ mmc->supply.vmmc,
+ ios->vdd);
+ if (host->ferror) {
+ dev_err(mmc_dev(mmc),
+ "failed to enable vmmc\n");
+ return;
+ }
+ }
if (!IS_ERR(mmc->supply.vqmmc)) {
host->ferror = regulator_enable(mmc->supply.vqmmc);
@@ -847,7 +853,9 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_OFF:
dev_dbg(mmc_dev(mmc), "power off!\n");
sunxi_mmc_reset_host(host);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled)
regulator_disable(mmc->supply.vqmmc);
host->vqmmc_enabled = false;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/9] pinctrl: sunxi: Deal with configless pins
From: Maxime Ripard @ 2016-10-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64gBi71W=+Tu2vz94xFDtuRNHUyVWK3ken8CSOWvK5t0g@mail.gmail.com>
On Tue, Oct 18, 2016 at 03:47:03PM +0800, Chen-Yu Tsai wrote:
> > @@ -342,6 +365,8 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
> > struct pinctrl_map *map,
> > unsigned num_maps)
> > {
> > + unsigned long *pinconfig;
>
> This looks out of place and context?
Yeah, sorry, it's just a leftover from the previous version. This has
been removed.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/a478c38b/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-19 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018163808.6318-1-eric@anholt.net>
On Tue, Oct 18, 2016 at 6:38 PM, Eric Anholt <eric@anholt.net> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The idea is to give useful names to GPIO lines that an implementer
> will be using from userspace, e.g. for maker type projects. These are
> user-visible using tools/gpio/lsgpio.c
>
> v2: Major rewrite by anholt: Flatten each GPIO line to a line in the
> file for better diffing, prefix all expansion header pins with
> "P<number>" or "P5HEADER_P<number>" and drop the mostly-unused
> GPIO_GEN<smallnumber> names in favor of GPIO<socgpionumber>, fix
> extra '[]' on a couple of lines, fix locations of SD_CARD_DETECT,
> CAM_GPIO and STATUS_LED, fix HDMI_HPD polarities, rewrite A+ using
> unreleased schematics.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
Generally looks good!
I fully trust your usage of he Pnn_* prefix, I assume this
makes a lot of sense to RPi users.
> Note: I haven't actually booted these and checked that the names line
> up, just tried to visually review them. Hopefully with more
> GPIO<number> values, it's easier to spot errors.
>
> The only other thing here I think I would do is drop the [] around
> names for behavior when pinmuxed. I find it more confusing than
> helpful.
I added this on the 96board HiKey instead of just leaving it blank.
The idea was to distinguish somehow between GPIO proper and
a GPIO line that is actually not used as GPIO. It is only really
reflecting the schematic, so whatever makes sense for someone
familiar with the schematics apply.
I think it is up to the .dts file maintainer to decide. May even be
different things that make sense on different boards.
> Linus, are these names considered ABI? Will we be locked into
> whatever set of names we merge and release? My assumption would be
> "yes".
It is ABI if there is a userspace making use of it. So once libs
like libmraa (is that the name?) and similar things that do userspace
GPIO start using it, it becomes ABI.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: fix uninitialized variable access
From: Arnd Bergmann @ 2016-10-19 12:09 UTC (permalink / raw)
To: linux-arm-kernel
The newly added st_fdma driver introduces a build warning for
allmodconfig when we add '-Wmaybe-uninitialized':
drivers/dma/st_fdma.c: In function 'st_fdma_probe':
drivers/dma/st_fdma.c:777:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The warning is correct, though this can't happen in practice
as the check is redundant (we don't get to this function if
the pointer is NULL). Even if the function were called with a
NULL of_node, the check is not needed because of_property_read_u32
can deal with a NULL argument by returning an error.
Removing the unnecessary code simplifies the function and avoids
the condition that we get the warning for.
Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/dma/st_fdma.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 515e1d4c43e8..232d3547a6a3 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -720,21 +720,11 @@ static int st_fdma_parse_dt(struct platform_device *pdev,
const struct st_fdma_driverdata *drvdata,
struct st_fdma_dev *fdev)
{
- struct device_node *np = pdev->dev.of_node;
- int ret;
-
- if (!np)
- goto err;
-
- ret = of_property_read_u32(np, "dma-channels", &fdev->nr_channels);
- if (ret)
- goto err;
-
snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
drvdata->name, drvdata->id);
-err:
- return ret;
+ return of_property_read_u32(pdev->dev.of_node, "dma-channels",
+ &fdev->nr_channels);
}
#define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Will Deacon @ 2016-10-19 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16572d35-bf69-1680-717a-d2815b121c32@redhat.com>
On Fri, Oct 14, 2016 at 08:45:43AM +0530, Pratyush Anand wrote:
>
>
> On Thursday 13 October 2016 10:33 PM, Pavel Labath wrote:
> >>I think, its easier to go with your implementation. So, I have taken
> >>> your patch and updated my perf/upstream_arm64_devel branch. May be you
> >>> can give it a test for your test cases.
> >I've checked out the new version of your branch, and it works great.
> >I'll write a patch with additional test cases to go on top of your
> >branch, as the tests there do not capture the bug I was fixing.
>
> That would be great. We can send them all together as V2.
Did you send a v2? I've been holding off reviewing this, but I just want
to make sure I didn't miss the update.
Cheers,
Will
^ permalink raw reply
* [PATCH] clk: uniphier: fix memory overrun bug
From: Masahiro Yamada @ 2016-10-19 11:49 UTC (permalink / raw)
To: linux-arm-kernel
The first loop of this "for" statement writes memory beyond the
allocated clk_hw_onecell_data.
It should be:
for (clk_num--; clk_num >= 0; clk_num--)
...
Or more simply:
while (--clk_num >= 0)
...
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/clk/uniphier/clk-uniphier-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
index f4e0f6b..84bc465 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -79,7 +79,7 @@ static int uniphier_clk_probe(struct platform_device *pdev)
hw_data->num = clk_num;
/* avoid returning NULL for unused idx */
- for (; clk_num >= 0; clk_num--)
+ while (--clk_num >= 0)
hw_data->hws[clk_num] = ERR_PTR(-EINVAL);
for (p = data; p->name; p++) {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] power/reset: at91-poweroff: timely shutdown LPDDR memories
From: Alexandre Belloni @ 2016-10-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019114420.15213-1-alexandre.belloni@free-electrons.com>
LPDDR memories can only handle up to 400 uncontrolled power off. Ensure the
proper power off sequence is used before shutting down the platform.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/power/reset/at91-poweroff.c | 54 +++++++++++++++++++++++++++++++-
drivers/power/reset/at91-sama5d2_shdwc.c | 49 ++++++++++++++++++++++++++++-
2 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
index e9e24df35f26..2579f025b90b 100644
--- a/drivers/power/reset/at91-poweroff.c
+++ b/drivers/power/reset/at91-poweroff.c
@@ -14,9 +14,12 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/printk.h>
+#include <soc/at91/at91sam9_ddrsdr.h>
+
#define AT91_SHDW_CR 0x00 /* Shut Down Control Register */
#define AT91_SHDW_SHDW BIT(0) /* Shut Down command */
#define AT91_SHDW_KEY (0xa5 << 24) /* KEY Password */
@@ -50,6 +53,7 @@ static const char *shdwc_wakeup_modes[] = {
static void __iomem *at91_shdwc_base;
static struct clk *sclk;
+static void __iomem *mpddrc_base;
static void __init at91_wakeup_status(void)
{
@@ -73,6 +77,29 @@ static void at91_poweroff(void)
writel(AT91_SHDW_KEY | AT91_SHDW_SHDW, at91_shdwc_base + AT91_SHDW_CR);
}
+static void at91_lpddr_poweroff(void)
+{
+ asm volatile(
+ /* Align to cache lines */
+ ".balign 32\n\t"
+
+ /* Ensure AT91_SHDW_CR is in the TLB by reading it */
+ " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+ /* Power down SDRAM0 */
+ " str %1, [%0, #" __stringify(AT91_DDRSDRC_LPR) "]\n\t"
+ /* Shutdown CPU */
+ " str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+ " b .\n\t"
+ :
+ : "r" (mpddrc_base),
+ "r" cpu_to_le32(AT91_DDRSDRC_LPDDR2_PWOFF),
+ "r" (at91_shdwc_base),
+ "r" cpu_to_le32(AT91_SHDW_KEY | AT91_SHDW_SHDW)
+ : "r0");
+}
+
static int at91_poweroff_get_wakeup_mode(struct device_node *np)
{
const char *pm;
@@ -124,6 +151,8 @@ static void at91_poweroff_dt_set_wakeup_mode(struct platform_device *pdev)
static int __init at91_poweroff_probe(struct platform_device *pdev)
{
struct resource *res;
+ struct device_node *np;
+ u32 ddr_type;
int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -150,12 +179,30 @@ static int __init at91_poweroff_probe(struct platform_device *pdev)
pm_power_off = at91_poweroff;
+ np = of_find_compatible_node(NULL, NULL, "atmel,sama5d3-ddramc");
+ if (!np)
+ return 0;
+
+ mpddrc_base = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!mpddrc_base)
+ return 0;
+
+ ddr_type = readl(mpddrc_base + AT91_DDRSDRC_MDR) & AT91_DDRSDRC_MD;
+ if ((ddr_type == AT91_DDRSDRC_MD_LPDDR2) ||
+ (ddr_type == AT91_DDRSDRC_MD_LPDDR3))
+ pm_power_off = at91_lpddr_poweroff;
+ else
+ iounmap(mpddrc_base);
+
return 0;
}
static int __exit at91_poweroff_remove(struct platform_device *pdev)
{
- if (pm_power_off == at91_poweroff)
+ if (pm_power_off == at91_poweroff ||
+ pm_power_off == at91_lpddr_poweroff)
pm_power_off = NULL;
clk_disable_unprepare(sclk);
@@ -163,6 +210,11 @@ static int __exit at91_poweroff_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id at91_ramc_of_match[] = {
+ { .compatible = "atmel,sama5d3-ddramc", },
+ { /* sentinel */ }
+};
+
static const struct of_device_id at91_poweroff_of_match[] = {
{ .compatible = "atmel,at91sam9260-shdwc", },
{ .compatible = "atmel,at91sam9rl-shdwc", },
diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
index 8a5ac9706c9c..90b0b5a70ce5 100644
--- a/drivers/power/reset/at91-sama5d2_shdwc.c
+++ b/drivers/power/reset/at91-sama5d2_shdwc.c
@@ -22,9 +22,12 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/printk.h>
+#include <soc/at91/at91sam9_ddrsdr.h>
+
#define SLOW_CLOCK_FREQ 32768
#define AT91_SHDW_CR 0x00 /* Shut Down Control Register */
@@ -75,6 +78,7 @@ struct shdwc {
*/
static struct shdwc *at91_shdwc;
static struct clk *sclk;
+static void __iomem *mpddrc_base;
static const unsigned long long sdwc_dbc_period[] = {
0, 3, 32, 512, 4096, 32768,
@@ -108,6 +112,29 @@ static void at91_poweroff(void)
at91_shdwc->at91_shdwc_base + AT91_SHDW_CR);
}
+static void at91_lpddr_poweroff(void)
+{
+ asm volatile(
+ /* Align to cache lines */
+ ".balign 32\n\t"
+
+ /* Ensure AT91_SHDW_CR is in the TLB by reading it */
+ " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+ /* Power down SDRAM0 */
+ " str %1, [%0, #" __stringify(AT91_DDRSDRC_LPR) "]\n\t"
+ /* Shutdown CPU */
+ " str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+ " b .\n\t"
+ :
+ : "r" (mpddrc_base),
+ "r" cpu_to_le32(AT91_DDRSDRC_LPDDR2_PWOFF),
+ "r" (at91_shdwc->at91_shdwc_base),
+ "r" cpu_to_le32(AT91_SHDW_KEY | AT91_SHDW_SHDW)
+ : "r0");
+}
+
static u32 at91_shdwc_debouncer_value(struct platform_device *pdev,
u32 in_period_us)
{
@@ -212,6 +239,8 @@ static int __init at91_shdwc_probe(struct platform_device *pdev)
{
struct resource *res;
const struct of_device_id *match;
+ struct device_node *np;
+ u32 ddr_type;
int ret;
if (!pdev->dev.of_node)
@@ -249,6 +278,23 @@ static int __init at91_shdwc_probe(struct platform_device *pdev)
pm_power_off = at91_poweroff;
+ np = of_find_compatible_node(NULL, NULL, "atmel,sama5d3-ddramc");
+ if (!np)
+ return 0;
+
+ mpddrc_base = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!mpddrc_base)
+ return 0;
+
+ ddr_type = readl(mpddrc_base + AT91_DDRSDRC_MDR) & AT91_DDRSDRC_MD;
+ if ((ddr_type == AT91_DDRSDRC_MD_LPDDR2) ||
+ (ddr_type == AT91_DDRSDRC_MD_LPDDR3))
+ pm_power_off = at91_lpddr_poweroff;
+ else
+ iounmap(mpddrc_base);
+
return 0;
}
@@ -256,7 +302,8 @@ static int __exit at91_shdwc_remove(struct platform_device *pdev)
{
struct shdwc *shdw = platform_get_drvdata(pdev);
- if (pm_power_off == at91_poweroff)
+ if (pm_power_off == at91_poweroff ||
+ pm_power_off == at91_lpddr_poweroff)
pm_power_off = NULL;
/* Reset values to disable wake-up features */
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/2] ARM: at91: define LPDDR types
From: Alexandre Belloni @ 2016-10-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019114420.15213-1-alexandre.belloni@free-electrons.com>
The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their
types.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
include/soc/at91/at91sam9_ddrsdr.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/soc/at91/at91sam9_ddrsdr.h b/include/soc/at91/at91sam9_ddrsdr.h
index dc10c52e0e91..393362bdb860 100644
--- a/include/soc/at91/at91sam9_ddrsdr.h
+++ b/include/soc/at91/at91sam9_ddrsdr.h
@@ -81,6 +81,7 @@
#define AT91_DDRSDRC_LPCB_POWER_DOWN 2
#define AT91_DDRSDRC_LPCB_DEEP_POWER_DOWN 3
#define AT91_DDRSDRC_CLKFR (1 << 2) /* Clock Frozen */
+#define AT91_DDRSDRC_LPDDR2_PWOFF (1 << 3) /* LPDDR Power Off */
#define AT91_DDRSDRC_PASR (7 << 4) /* Partial Array Self Refresh */
#define AT91_DDRSDRC_TCSR (3 << 8) /* Temperature Compensated Self Refresh */
#define AT91_DDRSDRC_DS (3 << 10) /* Drive Strength */
@@ -96,7 +97,9 @@
#define AT91_DDRSDRC_MD_SDR 0
#define AT91_DDRSDRC_MD_LOW_POWER_SDR 1
#define AT91_DDRSDRC_MD_LOW_POWER_DDR 3
+#define AT91_DDRSDRC_MD_LPDDR3 5
#define AT91_DDRSDRC_MD_DDR2 6 /* [SAM9 Only] */
+#define AT91_DDRSDRC_MD_LPDDR2 7
#define AT91_DDRSDRC_DBW (1 << 4) /* Data Bus Width */
#define AT91_DDRSDRC_DBW_32BITS (0 << 4)
#define AT91_DDRSDRC_DBW_16BITS (1 << 4)
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/2] ARM: at91: properly handle LPDDR poweroff
From: Alexandre Belloni @ 2016-10-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patch set improves LPDDR support on SoCs using the Atmel MPDDR controller.
LPDDR memories can only handle up to 400 uncontrolled power offs in their
life. The proper power off sequence has to be applied before shutting down the
SoC.
I'm not too happy with the code duplication but this is a design choice
that has been made before because both shutdown controllers are really
different apart from the shutdown itself.
I guess it is still better than slowly killing the LPDDR.
Changes in v2:
- Fix typos
- Add a comment for the dummy read access of AT91_SHDW_CR
- Properly set up pm_power_off in at91_poweroff_probe()
Alexandre Belloni (2):
ARM: at91: define LPDDR types
power/reset: at91-poweroff: timely shutdown LPDDR memories
drivers/power/reset/at91-poweroff.c | 54 +++++++++++++++++++++++++++++++-
drivers/power/reset/at91-sama5d2_shdwc.c | 49 ++++++++++++++++++++++++++++-
include/soc/at91/at91sam9_ddrsdr.h | 3 ++
3 files changed, 104 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [RFC PATCH 2/2] efi: arm64: add vmlinux debug link to the Image binary
From: Ard Biesheuvel @ 2016-10-19 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476877232-24308-1-git-send-email-ard.biesheuvel@linaro.org>
When building with debugging symbols, take the absolute path to the
vmlinux binary and add it to the special PE/COFF debug table entry.
This allows a debug EFI build to find the vmlinux binary, which is
very helpful in debugging, given that the offset where the Image is
first loaded by EFI is highly unpredictable.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/kernel/Makefile | 4 +++
arch/arm64/kernel/head.S | 34 +++++++++++++++++++-
arch/arm64/kernel/image.h | 3 ++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7d66bbaafc0c..1def85599fdb 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -55,3 +55,7 @@ obj-y += $(arm64-obj-y) vdso/ probes/
obj-m += $(arm64-obj-m)
head-y := head.o
extra-y += $(head-y) vmlinux.lds
+
+ifneq ($(CONFIG_DEBUG_INFO),)
+AFLAGS_head.o += -DVMLINUX_PATH="\"$(shell readlink -f $(objtree)/vmlinux)\""
+endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 427f6d3f084c..2f3fbd966de7 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -149,7 +149,7 @@ extra_header_fields:
.quad 0 // SizeOfHeapReserve
.quad 0 // SizeOfHeapCommit
.long 0 // LoaderFlags
- .long 0x6 // NumberOfRvaAndSizes
+ .long (section_table - .) / 8 // NumberOfRvaAndSizes
.quad 0 // ExportTable
.quad 0 // ImportTable
@@ -158,6 +158,11 @@ extra_header_fields:
.quad 0 // CertificationTable
.quad 0 // BaseRelocationTable
+#ifdef CONFIG_DEBUG_INFO
+ .long efi_debug_table - _head // DebugTable
+ .long efi_debug_table_size
+#endif
+
// Section table
section_table:
@@ -206,6 +211,33 @@ section_table:
efi_header_end:
#endif
+#ifdef CONFIG_DEBUG_INFO
+ __INITDATA
+
+efi_debug_table:
+ // EFI_IMAGE_DEBUG_DIRECTORY_ENTRY
+ .long 0 // Characteristics
+ .long 0 // TimeDateStamp
+ .short 0 // MajorVersion
+ .short 0 // MinorVersion
+ .long 2 // Type == EFI_IMAGE_DEBUG_TYPE_CODEVIEW
+ .long efi_debug_entry_size // SizeOfData
+ .long efi_debug_entry_offset // RVA
+ .long efi_debug_entry_offset // FileOffset
+
+ENTRY(efi_debug_entry)
+ // EFI_IMAGE_DEBUG_CODEVIEW_NB10_ENTRY
+ .long 0x3031424E // Signature
+ .long 0 // Unknown
+ .long 0 // Unknown2
+ .long 0 // Unknown3
+
+ .asciz VMLINUX_PATH
+
+ .set efi_debug_entry_size, . - efi_debug_entry
+ .set efi_debug_table_size, . - efi_debug_table
+#endif
+
__INIT
/*
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index c7fcb232fe47..ad5406f011c2 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -116,6 +116,9 @@ __efistub__end = KALLSYMS_HIDE(_end);
__efistub__edata = KALLSYMS_HIDE(_edata);
__efistub_screen_info = KALLSYMS_HIDE(screen_info);
+#ifdef CONFIG_DEBUG_INFO
+efi_debug_entry_offset = efi_debug_entry - _text;
+#endif
#endif
#endif /* __ASM_IMAGE_H */
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] efi: libstub: preserve .debug sections after absolute relocation check
From: Ard Biesheuvel @ 2016-10-19 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476877232-24308-1-git-send-email-ard.biesheuvel@linaro.org>
The build commands for the ARM and arm64 EFI stubs strips the .debug
sections and other sections that my legally contain absolute relocations,
in order to inspect the remaining sections for the presence of such
relocations.
This leaves us without debugging symbols in the stub for no good reason,
given that these sections are omitted from the kernel binary, and that
these relocations are thus only interpreted by the debugger.
So if the relocation check succeeds, invoke objcopy again, but this time,
leave the .debug sections in place. Note that these sections may refer
to ksymtab/kcrctab contents, so leave those in place as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/Makefile | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index c06945160a41..66584f173123 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -60,7 +60,7 @@ CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
extra-$(CONFIG_EFI_ARMSTUB) := $(lib-y)
lib-$(CONFIG_EFI_ARMSTUB) := $(patsubst %.o,%.stub.o,$(lib-y))
-STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab* -R *kcrctab*
+STUBCOPY_RM := -R .debug* -R *ksymtab* -R *kcrctab*
STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
--prefix-symbols=__efistub_
STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
@@ -68,11 +68,20 @@ STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
$(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,stubcopy)
+#
+# This calls objcopy twice: the first time it includes STUBCOPY_RM, and inspects
+# the result to ensure that the actual code itself does not contain any absolute
+# references. If this succeeds, the objcopy is performed a second time, but this
+# time the .debug and other sections are retained, given that we know that the
+# absolute relocations they may contain are harmless.
+#
quiet_cmd_stubcopy = STUBCPY $@
- cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then \
- $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y) \
- && (echo >&2 "$@: absolute symbol references not allowed in the EFI stub"; \
- rm -f $@; /bin/false); else /bin/false; fi
+ cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $(STUBCOPY_RM) $< $@; \
+ then if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); \
+ then (echo >&2 "$@: absolute symbol references not allowed in the EFI stub"; \
+ rm -f $@; /bin/false); \
+ else $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; fi \
+ else /bin/false; fi
#
# ARM discards the .data section because it disallows r/w data in the
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] efi/arm64: add vmlinux link to PE/COFF debug table
From: Ard Biesheuvel @ 2016-10-19 11:40 UTC (permalink / raw)
To: linux-arm-kernel
Much like GNU debug links, PE/COFF binaries can carry the patch to the binary
containing the debugging symbols. Since the kernel binary is loaded by UEFI
at an a priori unknown offset in the 1:1 mapping of physical memory, having
this information is useful for the debugger automation to find the file and
the offset, and load the symbols automatically.
So if we have debugging symbols to begin with (CONFIG_DEBUG_INFO=y), add the
absolute path to vmlinux to the PE/COFF debug table.
Ard Biesheuvel (2):
efi: libstub: preserve .debug sections after absolute relocation check
efi: arm64: add vmlinux debug link to the Image binary
arch/arm64/kernel/Makefile | 4 +++
arch/arm64/kernel/head.S | 34 +++++++++++++++++++-
arch/arm64/kernel/image.h | 3 ++
drivers/firmware/efi/libstub/Makefile | 19 ++++++++---
4 files changed, 54 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] efi: add support for seeding the RNG from a UEFI config table
From: Matt Fleming @ 2016-10-19 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9g1W8EfnJN2Y_Xgo=QKC1gHa95rjO32Dqt4uT+amzhnQ@mail.gmail.com>
On Wed, 19 Oct, at 12:13:55PM, Ard Biesheuvel wrote:
> On 19 October 2016 at 12:09, Mark Rutland <mark.rutland@arm.com> wrote:
>
> > I think to some extent this mush be treated as an ABI, given cases like
> > kexec.
> >
>
> Perhaps, yes. That would also allow GRUB or other EFI aware
> bootloaders to generate the seed.
If we're going to go down this route, we should try and get the GUID
into the UEFI spec.
^ permalink raw reply
* [PATCH] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Will Deacon @ 2016-10-19 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018111627.17366-1-andre.przywara@arm.com>
On Tue, Oct 18, 2016 at 12:16:27PM +0100, Andre Przywara wrote:
> Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
> errata-affected core") adds code to execute cache maintenance instructions
> in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
> It turns out that the address hasn't been checked to be a valid user
> space address, allowing userland to clean cache lines in kernel space.
> Fix this by introducing an access_ok() check before executing the
> instructions on behalf of userland, taking care of tagged pointers on
> the way.
>
> Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Cc: <stable@vger.kernel.org> # 4.8.x
> ---
> arch/arm64/include/asm/uaccess.h | 4 ++++
> arch/arm64/kernel/traps.c | 32 ++++++++++++++++++++++++++++----
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index bcaf6fb..f842b47 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -21,6 +21,7 @@
> /*
> * User space memory access functions
> */
> +#include <linux/bitops.h>
> #include <linux/kasan-checks.h>
> #include <linux/string.h>
> #include <linux/thread_info.h>
> @@ -103,6 +104,9 @@ static inline void set_fs(mm_segment_t fs)
> })
>
> #define access_ok(type, addr, size) __range_ok(addr, size)
> +#define access_ok_tagged(type, addr, size) access_ok(type, \
> + sign_extend64(addr, 55), \
> + size)
Sorry for not being clear, but I was actually thinking of a much simpler
macro, say detag_addr, that we could also expose as an asm variant for
the exception entry code.
If you want to modify access_ok, we could call detag_addr by default in
there.
Will
^ permalink raw reply
* [PATCH 1/2] efi: add support for seeding the RNG from a UEFI config table
From: Ard Biesheuvel @ 2016-10-19 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019110926.GG9616@leverpostej>
On 19 October 2016 at 12:09, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Ard,
>
> On Thu, Oct 06, 2016 at 11:27:25AM +0100, Ard Biesheuvel wrote:
>> Specify a Linux specific UEFI configuration table that carries some
>> random bits, and use the contents during early boot to seed the kernel's
>> random number generator. This allows much strong random numbers to be
>> generated early on.
>>
>> The entropy is fed to the kernel using add_device_randomness(), which is
>> documented as being appropriate for being called very early.
>>
>> Note that the config table could be generated by the EFI stub or by any
>> other UEFI driver or application (e.g., GRUB), but the random seed table
>> GUID and the associated functionality should be considered an internal
>> kernel interface (unless it is promoted to ABI later on)
>
> What does this mean for kexec? Won't each successive kernel look for the
> table and find the same seed?
>
Yes. Whether this is a problem or not is context dependent: for things
like kdump, I don't think anyone cares. For other cases, having some
seed may still be better than having no seed at all.
It does mean, however, that we have to preserve the memory this table
points to for kexec boots.
> I think to some extent this mush be treated as an ABI, given cases like
> kexec.
>
Perhaps, yes. That would also allow GRUB or other EFI aware
bootloaders to generate the seed.
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Boris Brezillon @ 2016-10-19 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37a5b543-e564-a496-d5cf-c215e798839f@baylibre.com>
On Wed, 19 Oct 2016 11:29:59 +0200
Neil Armstrong <narmstrong@baylibre.com> wrote:
> Hi Boris,
>
> On 10/18/2016 10:17 PM, Boris Brezillon wrote:
> > Hi Neil,
> >
> > On Tue, 18 Oct 2016 11:09:27 +0200
> > Neil Armstrong <narmstrong@baylibre.com> wrote:
> >
> >> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> >> This is a simple memory mapped NAND controller with single chip select and
> >> software ECC.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> >> drivers/mtd/nand/Kconfig | 5 +
> >> drivers/mtd/nand/Makefile | 1 +
> >> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> >> 4 files changed, 174 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> >> create mode 100644 drivers/mtd/nand/oxnas_nand.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> >> new file mode 100644
> >> index 0000000..83b684d
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> >> @@ -0,0 +1,24 @@
> >> +* Oxford Semiconductor OXNAS NAND Controller
> >> +
> >> +Please refer to nand.txt for generic information regarding MTD NAND bindings.
> >> +
> >> +Required properties:
> >> + - compatible: "oxsemi,ox820-nand"
> >> + - reg: Base address and length for NAND mapped memory.
> >> +
> >> +Optional Properties:
> >> + - clocks: phandle to the NAND gate clock if needed.
> >> + - resets: phandle to the NAND reset control if needed.
> >> +
> >> +Example:
> >> +
> >> +nand: nand at 41000000 {
> >> + compatible = "oxsemi,ox820-nand";
> >> + reg = <0x41000000 0x100000>;
> >> + nand-ecc-mode = "soft";
> >> + clocks = <&stdclk CLK_820_NAND>;
> >> + resets = <&reset RESET_NAND>;
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + status = "disabled";
> >> +};
> >
> > Can you switch to new DT representation for NAND controllers, with one
> > node for the NAND controller and NAND devices connected to this NAND
> > controller defined as sub-nodes of this NAND controller [1]?
>
> Yes, I was wondering if this existed... my bad, next time I will search further.
No problem. That's what reviews are here for ;-).
[...]
> >> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
[...]
> >> +
> >> +/* nand commands */
> >> +#define NAND_CMD_ALE BIT(18)
> >> +#define NAND_CMD_CLE BIT(19)
> >> +#define NAND_CMD_CS 0
> >
> > I guess this is zero here because you only support connecting a NAND to
> > CS0.
> > It's probably something like
> >
> > OX820_NAND_CS(x) ((x) << CS_FIELD_SHIFT)
>
> The hardware seems to be able to drive multiple chip selects, but no implementation does this.
> We will stick to CS0 only here for test reasons.
Then no need to define this _CS flag.
[...]
> >> + data->chip.cmd_ctrl = oxnas_nand_cmd_ctrl;
> >> + data->chip.chip_delay = 30;
> >> + data->chip.ecc.mode = NAND_ECC_SOFT;
> >> + data->chip.ecc.algo = NAND_ECC_HAMMING;
> >
> > Probably a good idea to support soft ECC as well...
I meant BCH, not soft :-).
>
> This was taken from plat_nand.c, I was not sure if it was necessary, will remove this and rely on DT attributes.
Yes, that's probably the best solution.
Regards,
Boris
^ permalink raw reply
* [PATCH 1/2] efi: add support for seeding the RNG from a UEFI config table
From: Mark Rutland @ 2016-10-19 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475749646-10844-2-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On Thu, Oct 06, 2016 at 11:27:25AM +0100, Ard Biesheuvel wrote:
> Specify a Linux specific UEFI configuration table that carries some
> random bits, and use the contents during early boot to seed the kernel's
> random number generator. This allows much strong random numbers to be
> generated early on.
>
> The entropy is fed to the kernel using add_device_randomness(), which is
> documented as being appropriate for being called very early.
>
> Note that the config table could be generated by the EFI stub or by any
> other UEFI driver or application (e.g., GRUB), but the random seed table
> GUID and the associated functionality should be considered an internal
> kernel interface (unless it is promoted to ABI later on)
What does this mean for kexec? Won't each successive kernel look for the
table and find the same seed?
I think to some extent this mush be treated as an ABI, given cases like
kexec.
Thanks,
Mark.
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/efi.c | 26 ++++++++++++++++++++
> include/linux/efi.h | 8 ++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 1ac199cd75e7..c8ae40f9b674 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -24,6 +24,7 @@
> #include <linux/of_fdt.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> +#include <linux/random.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
> #include <linux/ucs2_string.h>
> @@ -48,6 +49,7 @@ struct efi __read_mostly efi = {
> .esrt = EFI_INVALID_TABLE_ADDR,
> .properties_table = EFI_INVALID_TABLE_ADDR,
> .mem_attr_table = EFI_INVALID_TABLE_ADDR,
> + .rng_seed = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -438,6 +440,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
> {EFI_SYSTEM_RESOURCE_TABLE_GUID, "ESRT", &efi.esrt},
> {EFI_PROPERTIES_TABLE_GUID, "PROP", &efi.properties_table},
> {EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
> + {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", &efi.rng_seed},
> {NULL_GUID, NULL, NULL},
> };
>
> @@ -499,6 +502,29 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
> pr_cont("\n");
> set_bit(EFI_CONFIG_TABLES, &efi.flags);
>
> + if (efi.rng_seed != EFI_INVALID_TABLE_ADDR) {
> + struct linux_efi_random_seed *seed;
> + u32 size = 0;
> +
> + seed = early_memremap(efi.rng_seed, sizeof(*seed));
> + if (seed != NULL) {
> + size = seed->size;
> + early_memunmap(seed, sizeof(*seed));
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + if (size > 0) {
> + seed = early_memremap(efi.rng_seed,
> + sizeof(*seed) + size);
> + if (seed != NULL) {
> + add_device_randomness(seed->bits, seed->size);
> + early_memunmap(seed, sizeof(*seed) + size);
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + }
> + }
> +
> /* Parse the EFI Properties table if it exists */
> if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
> efi_properties_table_t *tbl;
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 2d089487d2da..85e28b138cdd 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -599,6 +599,7 @@ void efi_native_runtime_setup(void);
> */
> #define LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID EFI_GUID(0xe03fc20a, 0x85dc, 0x406e, 0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
> #define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
> +#define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
>
> typedef struct {
> efi_guid_t guid;
> @@ -872,6 +873,7 @@ extern struct efi {
> unsigned long esrt; /* ESRT table */
> unsigned long properties_table; /* properties table */
> unsigned long mem_attr_table; /* memory attributes table */
> + unsigned long rng_seed; /* UEFI firmware random seed */
> efi_get_time_t *get_time;
> efi_set_time_t *set_time;
> efi_get_wakeup_time_t *get_wakeup_time;
> @@ -1493,4 +1495,10 @@ efi_status_t efi_exit_boot_services(efi_system_table_t *sys_table,
> struct efi_boot_memmap *map,
> void *priv,
> efi_exit_boot_map_processing priv_func);
> +
> +struct linux_efi_random_seed {
> + u32 size;
> + u8 bits[];
> +};
> +
> #endif /* _LINUX_EFI_H */
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/2] efi: add support for seeding the RNG from a UEFI config table
From: Matt Fleming @ 2016-10-19 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475749646-10844-2-git-send-email-ard.biesheuvel@linaro.org>
(CC'ing other potentially interested randomness folks)
On Thu, 06 Oct, at 11:27:25AM, Ard Biesheuvel wrote:
> Specify a Linux specific UEFI configuration table that carries some
> random bits, and use the contents during early boot to seed the kernel's
> random number generator. This allows much strong random numbers to be
> generated early on.
>
> The entropy is fed to the kernel using add_device_randomness(), which is
> documented as being appropriate for being called very early.
>
> Note that the config table could be generated by the EFI stub or by any
> other UEFI driver or application (e.g., GRUB), but the random seed table
> GUID and the associated functionality should be considered an internal
> kernel interface (unless it is promoted to ABI later on)
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/efi.c | 26 ++++++++++++++++++++
> include/linux/efi.h | 8 ++++++
> 2 files changed, 34 insertions(+)
This series looks fine to me. I'm leaving the patch below for the
benefit of the Ted and Kees.
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 1ac199cd75e7..c8ae40f9b674 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -24,6 +24,7 @@
> #include <linux/of_fdt.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> +#include <linux/random.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
> #include <linux/ucs2_string.h>
> @@ -48,6 +49,7 @@ struct efi __read_mostly efi = {
> .esrt = EFI_INVALID_TABLE_ADDR,
> .properties_table = EFI_INVALID_TABLE_ADDR,
> .mem_attr_table = EFI_INVALID_TABLE_ADDR,
> + .rng_seed = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
>
> @@ -438,6 +440,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
> {EFI_SYSTEM_RESOURCE_TABLE_GUID, "ESRT", &efi.esrt},
> {EFI_PROPERTIES_TABLE_GUID, "PROP", &efi.properties_table},
> {EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
> + {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", &efi.rng_seed},
> {NULL_GUID, NULL, NULL},
> };
>
> @@ -499,6 +502,29 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
> pr_cont("\n");
> set_bit(EFI_CONFIG_TABLES, &efi.flags);
>
> + if (efi.rng_seed != EFI_INVALID_TABLE_ADDR) {
> + struct linux_efi_random_seed *seed;
> + u32 size = 0;
> +
> + seed = early_memremap(efi.rng_seed, sizeof(*seed));
> + if (seed != NULL) {
> + size = seed->size;
> + early_memunmap(seed, sizeof(*seed));
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + if (size > 0) {
> + seed = early_memremap(efi.rng_seed,
> + sizeof(*seed) + size);
> + if (seed != NULL) {
> + add_device_randomness(seed->bits, seed->size);
> + early_memunmap(seed, sizeof(*seed) + size);
> + } else {
> + pr_err("Could not map UEFI random seed!\n");
> + }
> + }
> + }
> +
> /* Parse the EFI Properties table if it exists */
> if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
> efi_properties_table_t *tbl;
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 2d089487d2da..85e28b138cdd 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -599,6 +599,7 @@ void efi_native_runtime_setup(void);
> */
> #define LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID EFI_GUID(0xe03fc20a, 0x85dc, 0x406e, 0xb9, 0x0e, 0x4a, 0xb5, 0x02, 0x37, 0x1d, 0x95)
> #define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
> +#define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
>
> typedef struct {
> efi_guid_t guid;
> @@ -872,6 +873,7 @@ extern struct efi {
> unsigned long esrt; /* ESRT table */
> unsigned long properties_table; /* properties table */
> unsigned long mem_attr_table; /* memory attributes table */
> + unsigned long rng_seed; /* UEFI firmware random seed */
> efi_get_time_t *get_time;
> efi_set_time_t *set_time;
> efi_get_wakeup_time_t *get_wakeup_time;
> @@ -1493,4 +1495,10 @@ efi_status_t efi_exit_boot_services(efi_system_table_t *sys_table,
> struct efi_boot_memmap *map,
> void *priv,
> efi_exit_boot_map_processing priv_func);
> +
> +struct linux_efi_random_seed {
> + u32 size;
> + u8 bits[];
> +};
> +
> #endif /* _LINUX_EFI_H */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/2] arm64: percpu: rewrite ll/sc loops in assembly
From: Will Deacon @ 2016-10-19 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476874784-16214-1-git-send-email-will.deacon@arm.com>
Writing the outer loop of an LL/SC sequence using do {...} while
constructs potentially allows the compiler to hoist memory accesses
between the STXR and the branch back to the LDXR. On CPUs that do not
guarantee forward progress of LL/SC loops when faced with memory
accesses to the same ERG (up to 2k) between the failed STXR and the
branch back, we may end up livelocking.
This patch avoids this issue in our percpu atomics by rewriting the
outer loop as part of the LL/SC inline assembly block.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/percpu.h | 120 +++++++++++++++++++---------------------
1 file changed, 56 insertions(+), 64 deletions(-)
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 2fee2f59288c..5394c8405e66 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -44,48 +44,44 @@ static inline unsigned long __percpu_##op(void *ptr, \
\
switch (size) { \
case 1: \
- do { \
- asm ("//__per_cpu_" #op "_1\n" \
- "ldxrb %w[ret], %[ptr]\n" \
+ asm ("//__per_cpu_" #op "_1\n" \
+ "1: ldxrb %w[ret], %[ptr]\n" \
#asm_op " %w[ret], %w[ret], %w[val]\n" \
- "stxrb %w[loop], %w[ret], %[ptr]\n" \
- : [loop] "=&r" (loop), [ret] "=&r" (ret), \
- [ptr] "+Q"(*(u8 *)ptr) \
- : [val] "Ir" (val)); \
- } while (loop); \
+ " stxrb %w[loop], %w[ret], %[ptr]\n" \
+ " cbnz %w[loop], 1b" \
+ : [loop] "=&r" (loop), [ret] "=&r" (ret), \
+ [ptr] "+Q"(*(u8 *)ptr) \
+ : [val] "Ir" (val)); \
break; \
case 2: \
- do { \
- asm ("//__per_cpu_" #op "_2\n" \
- "ldxrh %w[ret], %[ptr]\n" \
+ asm ("//__per_cpu_" #op "_2\n" \
+ "1: ldxrh %w[ret], %[ptr]\n" \
#asm_op " %w[ret], %w[ret], %w[val]\n" \
- "stxrh %w[loop], %w[ret], %[ptr]\n" \
- : [loop] "=&r" (loop), [ret] "=&r" (ret), \
- [ptr] "+Q"(*(u16 *)ptr) \
- : [val] "Ir" (val)); \
- } while (loop); \
+ " stxrh %w[loop], %w[ret], %[ptr]\n" \
+ " cbnz %w[loop], 1b" \
+ : [loop] "=&r" (loop), [ret] "=&r" (ret), \
+ [ptr] "+Q"(*(u16 *)ptr) \
+ : [val] "Ir" (val)); \
break; \
case 4: \
- do { \
- asm ("//__per_cpu_" #op "_4\n" \
- "ldxr %w[ret], %[ptr]\n" \
+ asm ("//__per_cpu_" #op "_4\n" \
+ "1: ldxr %w[ret], %[ptr]\n" \
#asm_op " %w[ret], %w[ret], %w[val]\n" \
- "stxr %w[loop], %w[ret], %[ptr]\n" \
- : [loop] "=&r" (loop), [ret] "=&r" (ret), \
- [ptr] "+Q"(*(u32 *)ptr) \
- : [val] "Ir" (val)); \
- } while (loop); \
+ " stxr %w[loop], %w[ret], %[ptr]\n" \
+ " cbnz %w[loop], 1b" \
+ : [loop] "=&r" (loop), [ret] "=&r" (ret), \
+ [ptr] "+Q"(*(u32 *)ptr) \
+ : [val] "Ir" (val)); \
break; \
case 8: \
- do { \
- asm ("//__per_cpu_" #op "_8\n" \
- "ldxr %[ret], %[ptr]\n" \
+ asm ("//__per_cpu_" #op "_8\n" \
+ "1: ldxr %[ret], %[ptr]\n" \
#asm_op " %[ret], %[ret], %[val]\n" \
- "stxr %w[loop], %[ret], %[ptr]\n" \
- : [loop] "=&r" (loop), [ret] "=&r" (ret), \
- [ptr] "+Q"(*(u64 *)ptr) \
- : [val] "Ir" (val)); \
- } while (loop); \
+ " stxr %w[loop], %[ret], %[ptr]\n" \
+ " cbnz %w[loop], 1b" \
+ : [loop] "=&r" (loop), [ret] "=&r" (ret), \
+ [ptr] "+Q"(*(u64 *)ptr) \
+ : [val] "Ir" (val)); \
break; \
default: \
BUILD_BUG(); \
@@ -150,44 +146,40 @@ static inline unsigned long __percpu_xchg(void *ptr, unsigned long val,
switch (size) {
case 1:
- do {
- asm ("//__percpu_xchg_1\n"
- "ldxrb %w[ret], %[ptr]\n"
- "stxrb %w[loop], %w[val], %[ptr]\n"
- : [loop] "=&r"(loop), [ret] "=&r"(ret),
- [ptr] "+Q"(*(u8 *)ptr)
- : [val] "r" (val));
- } while (loop);
+ asm ("//__percpu_xchg_1\n"
+ "1: ldxrb %w[ret], %[ptr]\n"
+ " stxrb %w[loop], %w[val], %[ptr]\n"
+ " cbnz %w[loop], 1b"
+ : [loop] "=&r"(loop), [ret] "=&r"(ret),
+ [ptr] "+Q"(*(u8 *)ptr)
+ : [val] "r" (val));
break;
case 2:
- do {
- asm ("//__percpu_xchg_2\n"
- "ldxrh %w[ret], %[ptr]\n"
- "stxrh %w[loop], %w[val], %[ptr]\n"
- : [loop] "=&r"(loop), [ret] "=&r"(ret),
- [ptr] "+Q"(*(u16 *)ptr)
- : [val] "r" (val));
- } while (loop);
+ asm ("//__percpu_xchg_2\n"
+ "1: ldxrh %w[ret], %[ptr]\n"
+ " stxrh %w[loop], %w[val], %[ptr]\n"
+ " cbnz %w[loop], 1b"
+ : [loop] "=&r"(loop), [ret] "=&r"(ret),
+ [ptr] "+Q"(*(u16 *)ptr)
+ : [val] "r" (val));
break;
case 4:
- do {
- asm ("//__percpu_xchg_4\n"
- "ldxr %w[ret], %[ptr]\n"
- "stxr %w[loop], %w[val], %[ptr]\n"
- : [loop] "=&r"(loop), [ret] "=&r"(ret),
- [ptr] "+Q"(*(u32 *)ptr)
- : [val] "r" (val));
- } while (loop);
+ asm ("//__percpu_xchg_4\n"
+ "1: ldxr %w[ret], %[ptr]\n"
+ " stxr %w[loop], %w[val], %[ptr]\n"
+ " cbnz %w[loop], 1b"
+ : [loop] "=&r"(loop), [ret] "=&r"(ret),
+ [ptr] "+Q"(*(u32 *)ptr)
+ : [val] "r" (val));
break;
case 8:
- do {
- asm ("//__percpu_xchg_8\n"
- "ldxr %[ret], %[ptr]\n"
- "stxr %w[loop], %[val], %[ptr]\n"
- : [loop] "=&r"(loop), [ret] "=&r"(ret),
- [ptr] "+Q"(*(u64 *)ptr)
- : [val] "r" (val));
- } while (loop);
+ asm ("//__percpu_xchg_8\n"
+ "1: ldxr %[ret], %[ptr]\n"
+ " stxr %w[loop], %[val], %[ptr]\n"
+ " cbnz %w[loop], 1b"
+ : [loop] "=&r"(loop), [ret] "=&r"(ret),
+ [ptr] "+Q"(*(u64 *)ptr)
+ : [val] "r" (val));
break;
default:
BUILD_BUG();
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] arm64: swp emulation: bound LL/SC retries before rescheduling
From: Will Deacon @ 2016-10-19 10:59 UTC (permalink / raw)
To: linux-arm-kernel
If a CPU does not implement a global monitor for certain memory types,
then userspace can attempt a kernel DoS by issuing SWP instructions
targetting the problematic memory (for example, a framebuffer mapped
with non-cacheable attributes).
The SWP emulation code protects against these sorts of attacks by
checking for pending signals and potentially rescheduling when the STXR
instruction fails during the emulation. Whilst this is good for avoiding
livelock, it harms emulation of legitimate SWP instructions on CPUs
where forward progress is not guaranteed if there are memory accesses to
the same reservation granule (up to 2k) between the failing STXR and
the retry of the LDXR.
This patch solves the problem by retrying the STXR a bounded number of
times (4) before breaking out of the LL/SC loop and looking for
something else to do.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/armv8_deprecated.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index 42ffdb54e162..b0988bb1bf64 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -280,35 +280,43 @@ static void __init register_insn_emulation_sysctl(struct ctl_table *table)
/*
* Error-checking SWP macros implemented using ldxr{b}/stxr{b}
*/
-#define __user_swpX_asm(data, addr, res, temp, B) \
+
+/* Arbitrary constant to ensure forward-progress of the LL/SC loop */
+#define __SWP_LL_SC_LOOPS 4
+
+#define __user_swpX_asm(data, addr, res, temp, temp2, B) \
__asm__ __volatile__( \
+ " mov %w3, %w7\n" \
ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN) \
- "0: ldxr"B" %w2, [%3]\n" \
- "1: stxr"B" %w0, %w1, [%3]\n" \
+ "0: ldxr"B" %w2, [%4]\n" \
+ "1: stxr"B" %w0, %w1, [%4]\n" \
" cbz %w0, 2f\n" \
- " mov %w0, %w4\n" \
+ " sub %w3, %w3, #1\n" \
+ " cbnz %w3, 0b\n" \
+ " mov %w0, %w5\n" \
" b 3f\n" \
"2:\n" \
" mov %w1, %w2\n" \
"3:\n" \
" .pushsection .fixup,\"ax\"\n" \
" .align 2\n" \
- "4: mov %w0, %w5\n" \
+ "4: mov %w0, %w6\n" \
" b 3b\n" \
" .popsection" \
_ASM_EXTABLE(0b, 4b) \
_ASM_EXTABLE(1b, 4b) \
ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN) \
- : "=&r" (res), "+r" (data), "=&r" (temp) \
- : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT) \
+ : "=&r" (res), "+r" (data), "=&r" (temp), "=&r" (temp2) \
+ : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT), \
+ "i" (__SWP_LL_SC_LOOPS) \
: "memory")
-#define __user_swp_asm(data, addr, res, temp) \
- __user_swpX_asm(data, addr, res, temp, "")
-#define __user_swpb_asm(data, addr, res, temp) \
- __user_swpX_asm(data, addr, res, temp, "b")
+#define __user_swp_asm(data, addr, res, temp, temp2) \
+ __user_swpX_asm(data, addr, res, temp, temp2, "")
+#define __user_swpb_asm(data, addr, res, temp, temp2) \
+ __user_swpX_asm(data, addr, res, temp, temp2, "b")
/*
* Bit 22 of the instruction encoding distinguishes between
@@ -328,12 +336,12 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
}
while (1) {
- unsigned long temp;
+ unsigned long temp, temp2;
if (type == TYPE_SWPB)
- __user_swpb_asm(*data, address, res, temp);
+ __user_swpb_asm(*data, address, res, temp, temp2);
else
- __user_swp_asm(*data, address, res, temp);
+ __user_swp_asm(*data, address, res, temp, temp2);
if (likely(res != -EAGAIN) || signal_pending(current))
break;
--
2.1.4
^ permalink raw reply related
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-10-19 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU=iTps+YfyeUyhPQkgSYHuG1hCLMFUTVOcPsHgbiPgSw@mail.gmail.com>
On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote:
> >> +static const struct renesas_family fam_rza __initconst = {
> >> + .name = "RZ/A",
> >> +};
> >
> > I'm not sure about the relationship between this one and the others,
> > maybe it should be treated in the same way as emev2 and left out from
> > this driver?
>
> While RZ/A doesn't have a version registers (AFAIK), it shares several
> drivers with the other SoCs (SH/R-Mobile, R-Car).
> Hence I'd like to keep it, so we can match for it in these drivers when
> needed. It has e.g. a different variant of the serial port (SCIF), more
> closely to the one on SH2 rather than SH4.
I'd prefer seeing a separate soc driver for that one.
> >> +static const struct renesas_family fam_rmobile __initconst = {
> >> + .name = "R-Mobile",
> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
> >> +};
> >> +
> >> +static const struct renesas_family fam_rcar_gen1 __initconst = {
> >> + .name = "R-Car Gen1",
> >> + .reg = 0xff000044, /* PRR (Product Register) */
> >> +};
> >> +
> >> +static const struct renesas_family fam_rcar_gen2 __initconst = {
> >> + .name = "R-Car Gen2",
> >> + .reg = 0xff000044, /* PRR (Product Register) */
> >> +};
> >> +
> >> +static const struct renesas_family fam_rcar_gen3 __initconst = {
> >> + .name = "R-Car Gen3",
> >> + .reg = 0xfff00044, /* PRR (Product Register) */
> >> +};
> >> +
> >> +static const struct renesas_family fam_rzg __initconst = {
> >> + .name = "RZ/G",
> >> + .reg = 0xff000044, /* PRR (Product Register) */
> >> +};
> >> +
> >> +static const struct renesas_family fam_shmobile __initconst = {
> >> + .name = "SH-Mobile",
> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
> >> +};
> >
> > These seem to fall into two distinct categories, maybe there is a
> > better way to group them. What device contain the two kinds of
> > registers (PRR, CCCR)?
>
> Actually there are three (notice the extra "f" on R-Car Gen3 ;-)
I see. Hopefully this is just the same register block at a different
location though.
> Some SoCs have only CCCR, others have only PRR, some have both.
> On some SoCs one of them can be accessed from the RealTime CPU
> core (SH) only.
> On some SoCs the register is not documented, but present.
> If the PRR exists, it's a better choice, as it contains additional information
> in the high order bits (representing the presence of each big (CA15/CA57),
> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
> information, though.
>
> Grouping them in some other way means we would loose the family name,
> which is exposed through soc_dev_attr->family.
> The usefulness of family names is debatable though, as this is more an
> issue of marketing business.
How about having a table to look up the family name by the value
of the PRR or CCCR then?
> > Hardcoding the register address seems rather ugly here, so maybe
> > there is a way to have two separate probe methods based on the
> > surrounding register range, and then bind to that?
>
> There's no simple relation between CCCR/PRR and other register blocks.
> I prefer not to add these to DT, as that would add one more worm to the
> backwards compatibility can.
Hmm, I understand the concern about compatibility with existing DT files,
but I also really hate to see hardcoded register addresses.
Any reason against requiring the DT node for future chips though?
How about this:
The driver could report the hardcoded strings for the SoCs it already
knows about (you have the table anyway) and not report the revision
unless there is a regmap containing the CCCR or the PRR, in which
case you use that. Future SoCs will provide the PRR (I assume
CCCR is only used on the older ones) through a syscon regmap
that we can use to find out the exact revision as well.
The existing DT files can gain the syscon device so you can report
the revision on those machines as well, unless you use an old DTB.
> >> +static const struct of_device_id renesas_socs[] __initconst = {
> >> +#ifdef CONFIG_ARCH_EMEV2
> >> + { .compatible = "renesas,emev2", .data = &soc_emev2 },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R7S72100
> >> + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R8A73A4
> >
> > I think the #ifdefs here will result in warnings for unused symbols
> > when the Kconfig symbols are disabled.
>
> Originally I had __maybe_unused, but it didn't seem to be needed.
> Do you know which compiler needs it, so I can check?
Ah, I remember now: gcc doesn't warn for 'static const' variables
unless we pass -Wunused-const, which should be enabled with "make W=1",
and we might make that the default in the future (after fixing the
handful of drivers currently relying on this).
Why not just drop all the #ifdef here? There should be very little
overhead in size, especially if all the data is __initconst.
Arnd
^ permalink raw reply
* [PATCH v3 0/3] usb/phy: Add Amlogic Meson8b and GXBB USB support
From: Kishon Vijay Abraham I @ 2016-10-19 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCoVOxyVYdNxeNyUhAK+T1+gBW0d1oDUgVpOZZHBjN9Wg@mail.gmail.com>
Hi,
On Friday 14 October 2016 01:57 AM, Martin Blumenstingl wrote:
> Hi Kishon,
>
> On Sat, Oct 1, 2016 at 2:18 PM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> Martin Blumenstingl (3):
>> Documentation: dt-bindings: update the meson-usb2-phy example
>> Documentation: dt-bindings: rename meson-usb2-phy to meson8b-usb2-phy
> these two already got an ACK by the devicetree maintainers
>
>> phy: meson: add USB2 PHY support for Meson8b and GXBB
> did you already have time to review the USB2 PHY driver from patch 3/3?
> please let me know if there's something we have to change, then I'll
> take care of it
>
> would you like to get all patches through the PHY tree or should Kevin
> take some of these?
while I have merged the patches to linux-phy -next, please update the
MAINTAINER for meson phy driver.
Thanks
Kishon
^ 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