* [PATCH -next] i2c: digicolor: use clk_disable_unprepare instead of clk_unprepare
From: Wei Yongjun @ 2016-10-29 16:31 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
since clk_prepare_enable() is used to get i2c->clk, we should
use clk_disable_unprepare() to release it for the error path.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/i2c/busses/i2c-digicolor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-digicolor.c b/drivers/i2c/busses/i2c-digicolor.c
index 49f2084..50813a2 100644
--- a/drivers/i2c/busses/i2c-digicolor.c
+++ b/drivers/i2c/busses/i2c-digicolor.c
@@ -347,7 +347,7 @@ static int dc_i2c_probe(struct platform_device *pdev)
ret = i2c_add_adapter(&i2c->adap);
if (ret < 0) {
- clk_unprepare(i2c->clk);
+ clk_disable_unprepare(i2c->clk);
return ret;
}
^ permalink raw reply related
* [GIT PULL] ARM: uniphier: fixes for v4.9
From: Olof Johansson @ 2016-10-29 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATGyfiYYsxDeyhjerG16MMro--sxCC1nwpCu-9fN9+dBQ@mail.gmail.com>
On Sat, Oct 22, 2016 at 11:28:51PM +0900, Masahiro Yamada wrote:
> Hi Arnd, Olof,
>
> Here are some fixes for v4.9.
> It is touching a reset controller driver, but Philipp gave me Acked-by
> for including it in my pull-request.
>
>
> Here is a question; do you have a chance to send a pull-request for fixes
> to Linus before -rc4? In my understanding, pull requests for the next merge
> window are generally required to be based on a tag prior to -rc4.
> In the previous development cycle, I remember the fixes pull-request was
> sent around v4.8-rc7. In this case, it would be a problem if a fixup commit
> and a new-development commit have a conflict with each other.
> If the first round of fixes pull-request is sent before -rc4, commits for
> the next merge window can be queued up based on -rc4 without any conflicts.
We send periodic pull requests, usually once per -rc (but sometimes we skip
one). These should make it into -rc3.
The base for next merge window should be based on as old a release as
practical, but what you can do is that you can use the fixes branch as the base
if you need to (just don't rebase it).
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
> tags/uniphier-fixes-v4.9
>
> for you to fetch changes up to 8e68c65d111a57a4cbe41dc886bb2a1e671e0b6e:
>
> arm64: dts: uniphier: change MIO node to SD control node (2016-10-22
> 21:59:21 +0900)
>
> ----------------------------------------------------------------
> UniPhier ARM SoC fixes for v4.9
>
> - Add "select ARCH_HAS_RESET_CONTROLLER" in Kconfig
> - Rename wrongly-named mioctrl to sdctrl
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Olof Johansson @ 2016-10-29 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024140622.GM30578@tiger>
On Mon, Oct 24, 2016 at 10:06:22PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.9
>
> for you to fetch changes up to 4edd601c5a9c5094daa714e65063e623826f3bcc:
>
> ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031 (2016-10-24 21:26:01 +0800)
>
> ----------------------------------------------------------------
> The i.MX fixes for 4.9:
> - A couple of patches from Fabio to fix the GPC power domain regression
> which is caused by PM Domain core change 0159ec670763dd
> ("PM / Domains: Verify the PM domain is present when adding a
> provider"), and a related kernel crash seen with multi_v7_defconfig
> build.
> - Correct the PHY ID mask for AR8031 to match phy driver code.
> - Apply new added timer erratum A008585 for LS1043A and LS2080A SoC.
> - Correct vf610 global timer IRQ flag to avoid warning from gic driver
> after commit 992345a58e0c ("irqchip/gic: WARN if setting the
> interrupt type for a PPI fails").
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Broadcom ARM64 Device Tree fixes for 4.9
From: Olof Johansson @ 2016-10-29 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477331005-32163-1-git-send-email-f.fainelli@gmail.com>
On Mon, Oct 24, 2016 at 10:43:25AM -0700, Florian Fainelli wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.9/devicetree-arm64-fixes
>
> for you to fetch changes up to 963d790468a2f581abf039b45edac79af5e16e55:
>
> arm64: dts: Updated NAND DT properties for NS2 SVK (2016-10-23 14:50:20 -0700)
>
> ----------------------------------------------------------------
> This pull request contains a single fix for Broadcom ARM64-based SoCs:
>
> - Ray adds the required bus width and OOB sector size properties to the
> Northstar 2 SVK reference board in order for the NAND controller to work
> properly
>
> ----------------------------------------------------------------
> Ray Jui (1):
> arm64: dts: Updated NAND DT properties for NS2 SVK
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Rockchip dts64 fixes for 4.9-rc
From: Olof Johansson @ 2016-10-29 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2007497.qXCdMDh9Wq@phil>
On Fri, Oct 28, 2016 at 11:22:20AM +0200, Heiko Stuebner wrote:
> Hi Arnd, Kevin, Olof,
>
> please find below two fixes for 64bit Rockchip boards. One makes
> binds/unbinds fail and the other drops one unnecessary property.
>
> Please pull.
> Thanks
> Heiko
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.9-rockchip-dts64-fixes1
>
> for you to fetch changes up to 7c6273194445fe1316084d3096f9311c3dfa4da6:
>
> arm64: dts: rockchip: remove the abuse of keep-power-in-suspend (2016-10-18 20:03:54 +0200)
>
> ----------------------------------------------------------------
> Correct regulator handling on Rockchip arm64 boards to make
> bind/unbind calls work correctly and remove a sdio-only
> property from non-sdio mmc hosts, that accidentially was
> added there.
>
> ----------------------------------------------------------------
> Shawn Lin (2):
> arm64: dts: rockchip: remove always-on and boot-on from vcc_sd
> arm64: dts: rockchip: remove the abuse of keep-power-in-suspend
Merged, thanks.
-Olof
^ permalink raw reply
* Applied "spi: sun4i: Allow transfers larger than FIFO size" to the spi tree
From: Mark Brown @ 2016-10-29 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477465231-17704-2-git-send-email-mr.nuke.me@gmail.com>
The patch
spi: sun4i: Allow transfers larger than FIFO size
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 196737912da5eab055489e0635662a3b7adef6eb Mon Sep 17 00:00:00 2001
From: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Date: Wed, 26 Oct 2016 00:00:31 -0700
Subject: [PATCH] spi: sun4i: Allow transfers larger than FIFO size
SPI transfers were limited to one FIFO depth, which is 64 bytes.
This was an artificial limitation, however, as the hardware can handle
much larger bursts. To accommodate this, we enable the interrupt when
the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
handler. The 3/4 ratio was chosen arbitrarily, with the intention to
reduce the potential number of interrupts.
Since the SUN4I_CTL_TP bit is set, the hardware will pause
transmission whenever the FIFO is full, so there is no risk of losing
data if we can't service the interrupt in time.
For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-sun4i.c | 75 +++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 4969dc10684a..c5cd635c28f3 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -46,6 +46,8 @@
#define SUN4I_CTL_TP BIT(18)
#define SUN4I_INT_CTL_REG 0x0c
+#define SUN4I_INT_CTL_RF_F34 BIT(4)
+#define SUN4I_INT_CTL_TF_E34 BIT(12)
#define SUN4I_INT_CTL_TC BIT(16)
#define SUN4I_INT_STA_REG 0x10
@@ -61,11 +63,14 @@
#define SUN4I_CLK_CTL_CDR1(div) (((div) & SUN4I_CLK_CTL_CDR1_MASK) << 8)
#define SUN4I_CLK_CTL_DRS BIT(12)
+#define SUN4I_MAX_XFER_SIZE 0xffffff
+
#define SUN4I_BURST_CNT_REG 0x20
-#define SUN4I_BURST_CNT(cnt) ((cnt) & 0xffffff)
+#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
#define SUN4I_XMIT_CNT_REG 0x24
-#define SUN4I_XMIT_CNT(cnt) ((cnt) & 0xffffff)
+#define SUN4I_XMIT_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
+
#define SUN4I_FIFO_STA_REG 0x28
#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -96,6 +101,31 @@ static inline void sun4i_spi_write(struct sun4i_spi *sspi, u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
}
+static inline u32 sun4i_spi_get_tx_fifo_count(struct sun4i_spi *sspi)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_FIFO_STA_REG);
+
+ reg >>= SUN4I_FIFO_STA_TF_CNT_BITS;
+
+ return reg & SUN4I_FIFO_STA_TF_CNT_MASK;
+}
+
+static inline void sun4i_spi_enable_interrupt(struct sun4i_spi *sspi, u32 mask)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+
+ reg |= mask;
+ sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
+static inline void sun4i_spi_disable_interrupt(struct sun4i_spi *sspi, u32 mask)
+{
+ u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+
+ reg &= ~mask;
+ sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
static inline void sun4i_spi_drain_fifo(struct sun4i_spi *sspi, int len)
{
u32 reg, cnt;
@@ -118,10 +148,13 @@ static inline void sun4i_spi_drain_fifo(struct sun4i_spi *sspi, int len)
static inline void sun4i_spi_fill_fifo(struct sun4i_spi *sspi, int len)
{
+ u32 cnt;
u8 byte;
- if (len > sspi->len)
- len = sspi->len;
+ /* See how much data we can fit */
+ cnt = SUN4I_FIFO_DEPTH - sun4i_spi_get_tx_fifo_count(sspi);
+
+ len = min3(len, (int)cnt, sspi->len);
while (len--) {
byte = sspi->tx_buf ? *sspi->tx_buf++ : 0;
@@ -184,10 +217,10 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
u32 reg;
/* We don't support transfer larger than the FIFO */
- if (tfr->len > SUN4I_FIFO_DEPTH)
+ if (tfr->len > SUN4I_MAX_XFER_SIZE)
return -EMSGSIZE;
- if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
+ if (tfr->tx_buf && tfr->len >= SUN4I_MAX_XFER_SIZE)
return -EMSGSIZE;
reinit_completion(&sspi->done);
@@ -286,7 +319,11 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
/* Enable the interrupts */
- sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
+ sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TC |
+ SUN4I_INT_CTL_RF_F34);
+ /* Only enable Tx FIFO interrupt if we really need it */
+ if (tx_len > SUN4I_FIFO_DEPTH)
+ sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);
/* Start the transfer */
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
@@ -306,7 +343,6 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
goto out;
}
- sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
out:
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, 0);
@@ -322,10 +358,33 @@ static irqreturn_t sun4i_spi_handler(int irq, void *dev_id)
/* Transfer complete */
if (status & SUN4I_INT_CTL_TC) {
sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_TC);
+ sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
complete(&sspi->done);
return IRQ_HANDLED;
}
+ /* Receive FIFO 3/4 full */
+ if (status & SUN4I_INT_CTL_RF_F34) {
+ sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+ /* Only clear the interrupt _after_ draining the FIFO */
+ sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_RF_F34);
+ return IRQ_HANDLED;
+ }
+
+ /* Transmit FIFO 3/4 empty */
+ if (status & SUN4I_INT_CTL_TF_E34) {
+ sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+
+ if (!sspi->len)
+ /* nothing left to transmit */
+ sun4i_spi_disable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);
+
+ /* Only clear the interrupt _after_ re-seeding the FIFO */
+ sun4i_spi_write(sspi, SUN4I_INT_STA_REG, SUN4I_INT_CTL_TF_E34);
+
+ return IRQ_HANDLED;
+ }
+
return IRQ_NONE;
}
--
2.10.1
^ permalink raw reply related
* [PATCH v2 11/19] edac: rename edac_core.h to edac_mc.h
From: Mauro Carvalho Chehab @ 2016-10-29 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1477765574.git.mchehab@s-opensource.com>
Now, all left at edac_core.h are at drivers/edac/edac_mc.c,
so rename it to edac_mc.h.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/edac/altera_edac.c | 1 -
drivers/edac/amd64_edac.h | 2 +-
drivers/edac/amd76x_edac.c | 2 +-
drivers/edac/amd8111_edac.c | 1 -
drivers/edac/amd8131_edac.c | 1 -
drivers/edac/cell_edac.c | 2 +-
drivers/edac/cpc925_edac.c | 1 -
drivers/edac/e752x_edac.c | 2 +-
drivers/edac/e7xxx_edac.c | 2 +-
drivers/edac/edac_mc.c | 2 +-
drivers/edac/{edac_core.h => edac_mc.h} | 11 ++++-------
drivers/edac/edac_mc_sysfs.c | 2 +-
drivers/edac/edac_module.c | 2 +-
drivers/edac/edac_module.h | 4 +++-
drivers/edac/fsl_ddr_edac.c | 1 -
drivers/edac/ghes_edac.c | 2 +-
drivers/edac/highbank_l2_edac.c | 1 -
drivers/edac/highbank_mc_edac.c | 1 -
drivers/edac/i3000_edac.c | 2 +-
drivers/edac/i3200_edac.c | 2 +-
drivers/edac/i5000_edac.c | 2 +-
drivers/edac/i5100_edac.c | 1 -
drivers/edac/i5400_edac.c | 2 +-
drivers/edac/i7300_edac.c | 2 +-
drivers/edac/i7core_edac.c | 2 +-
drivers/edac/i82443bxgx_edac.c | 2 +-
drivers/edac/i82860_edac.c | 2 +-
drivers/edac/i82875p_edac.c | 2 +-
drivers/edac/i82975x_edac.c | 2 +-
drivers/edac/ie31200_edac.c | 2 +-
drivers/edac/layerscape_edac.c | 2 +-
drivers/edac/mpc85xx_edac.c | 1 -
drivers/edac/mv64x60_edac.c | 1 -
drivers/edac/octeon_edac-l2c.c | 1 -
drivers/edac/octeon_edac-lmc.c | 1 -
drivers/edac/octeon_edac-pc.c | 1 -
drivers/edac/octeon_edac-pci.c | 1 -
drivers/edac/pasemi_edac.c | 2 +-
drivers/edac/ppc4xx_edac.c | 2 +-
drivers/edac/r82600_edac.c | 2 +-
drivers/edac/sb_edac.c | 2 +-
drivers/edac/skx_edac.c | 2 +-
drivers/edac/synopsys_edac.c | 2 +-
drivers/edac/tile_edac.c | 2 +-
drivers/edac/x38_edac.c | 2 +-
drivers/edac/xgene_edac.c | 1 -
46 files changed, 36 insertions(+), 52 deletions(-)
rename drivers/edac/{edac_core.h => edac_mc.h} (95%)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 58d3e2b39b5b..798e9440d338 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -35,7 +35,6 @@
#include <linux/uaccess.h>
#include "altera_edac.h"
-#include "edac_core.h"
#include "edac_module.h"
#define EDAC_MOD_STR "altera_edac"
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index c08870479054..35e1f9e14777 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -17,7 +17,7 @@
#include <linux/mmzone.h>
#include <linux/edac.h>
#include <asm/msr.h>
-#include "edac_core.h"
+#include "edac_module.h"
#include "mce_amd.h"
#define amd64_debug(fmt, arg...) \
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 3a501b530e11..a7450275ad28 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -17,7 +17,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define AMD76X_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "amd76x_edac"
diff --git a/drivers/edac/amd8111_edac.c b/drivers/edac/amd8111_edac.c
index 2b63f7c2d6d2..b5786cfded3a 100644
--- a/drivers/edac/amd8111_edac.c
+++ b/drivers/edac/amd8111_edac.c
@@ -29,7 +29,6 @@
#include <linux/pci_ids.h>
#include <asm/io.h>
-#include "edac_core.h"
#include "edac_module.h"
#include "amd8111_edac.h"
diff --git a/drivers/edac/amd8131_edac.c b/drivers/edac/amd8131_edac.c
index a5c680561c73..8851c33d7d24 100644
--- a/drivers/edac/amd8131_edac.c
+++ b/drivers/edac/amd8131_edac.c
@@ -29,7 +29,6 @@
#include <linux/edac.h>
#include <linux/pci_ids.h>
-#include "edac_core.h"
#include "edac_module.h"
#include "amd8131_edac.h"
diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index a9259b069dcd..bc1f3416400e 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -19,7 +19,7 @@
#include <asm/machdep.h>
#include <asm/cell-regs.h>
-#include "edac_core.h"
+#include "edac_module.h"
struct cell_edac_priv
{
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index 682288ced4ac..837b62c4993d 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -27,7 +27,6 @@
#include <linux/platform_device.h>
#include <linux/gfp.h>
-#include "edac_core.h"
#include "edac_module.h"
#define CPC925_EDAC_REVISION " Ver: 1.0.0"
diff --git a/drivers/edac/e752x_edac.c b/drivers/edac/e752x_edac.c
index b2d71388172b..1a352cae1f52 100644
--- a/drivers/edac/e752x_edac.c
+++ b/drivers/edac/e752x_edac.c
@@ -24,7 +24,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define E752X_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "e752x_edac"
diff --git a/drivers/edac/e7xxx_edac.c b/drivers/edac/e7xxx_edac.c
index ece3aef16bb1..67ef07aed923 100644
--- a/drivers/edac/e7xxx_edac.c
+++ b/drivers/edac/e7xxx_edac.c
@@ -30,7 +30,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define E7XXX_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "e7xxx_edac"
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index c3ee3ad98a63..6f08dfa18e5e 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -30,7 +30,7 @@
#include <linux/bitops.h>
#include <asm/uaccess.h>
#include <asm/page.h>
-#include "edac_core.h"
+#include "edac_mc.h"
#include "edac_module.h"
#include <ras/ras_event.h>
diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_mc.h
similarity index 95%
rename from drivers/edac/edac_core.h
rename to drivers/edac/edac_mc.h
index 3e11d9d85462..b62d9bad9859 100644
--- a/drivers/edac/edac_core.h
+++ b/drivers/edac/edac_mc.h
@@ -1,5 +1,5 @@
/*
- * Defines, structures, APIs for edac_core module
+ * Defines, structures, APIs for edac_mc module
*
* (C) 2007 Linux Networx (http://lnxi.com)
* This file may be distributed under the terms of the
@@ -17,8 +17,8 @@
*
*/
-#ifndef _EDAC_CORE_H_
-#define _EDAC_CORE_H_
+#ifndef _EDAC_MC_H_
+#define _EDAC_MC_H_
#include <linux/kernel.h>
#include <linux/types.h>
@@ -35,9 +35,6 @@
#include <linux/workqueue.h>
#include <linux/edac.h>
-#include "edac_pci.h"
-#include "edac_device.h"
-
#if PAGE_SHIFT < 20
#define PAGES_TO_MiB(pages) ((pages) >> (20 - PAGE_SHIFT))
#define MiB_TO_PAGES(mb) ((mb) << (20 - PAGE_SHIFT))
@@ -131,4 +128,4 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
*/
extern char *edac_op_state_to_string(int op_state);
-#endif /* _EDAC_CORE_H_ */
+#endif /* _EDAC_MC_H_ */
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4e0f8e720ad9..39dbab7d62f1 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -19,7 +19,7 @@
#include <linux/pm_runtime.h>
#include <linux/uaccess.h>
-#include "edac_core.h"
+#include "edac_mc.h"
#include "edac_module.h"
/* MC EDAC Controls, setable by module parameter, and sysfs */
diff --git a/drivers/edac/edac_module.c b/drivers/edac/edac_module.c
index 5f8543be995a..172598a27d7d 100644
--- a/drivers/edac/edac_module.c
+++ b/drivers/edac/edac_module.c
@@ -12,7 +12,7 @@
*/
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_mc.h"
#include "edac_module.h"
#define EDAC_VERSION "Ver: 3.0.0"
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index cfaacb99c973..014871e169cc 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -10,7 +10,9 @@
#ifndef __EDAC_MODULE_H__
#define __EDAC_MODULE_H__
-#include "edac_core.h"
+#include "edac_mc.h"
+#include "edac_pci.h"
+#include "edac_device.h"
/*
* INTERNAL EDAC MODULE:
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index 9774f52f0c3e..4e9608a958e7 100644
--- a/drivers/edac/fsl_ddr_edac.c
+++ b/drivers/edac/fsl_ddr_edac.c
@@ -28,7 +28,6 @@
#include <linux/of_device.h>
#include <linux/of_address.h>
#include "edac_module.h"
-#include "edac_core.h"
#include "fsl_ddr_edac.h"
#define EDAC_MOD_STR "fsl_ddr_edac"
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index e3fa4390f846..4e61a6229dd2 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -14,7 +14,7 @@
#include <acpi/ghes.h>
#include <linux/edac.h>
#include <linux/dmi.h>
-#include "edac_core.h"
+#include "edac_module.h"
#include <ras/ras_event.h>
#define GHES_EDAC_REVISION " Ver: 1.0.0"
diff --git a/drivers/edac/highbank_l2_edac.c b/drivers/edac/highbank_l2_edac.c
index 2f193668ebc7..cd9a2bb7c548 100644
--- a/drivers/edac/highbank_l2_edac.c
+++ b/drivers/edac/highbank_l2_edac.c
@@ -21,7 +21,6 @@
#include <linux/platform_device.h>
#include <linux/of_platform.h>
-#include "edac_core.h"
#include "edac_module.h"
#define SR_CLR_SB_ECC_INTR 0x0
diff --git a/drivers/edac/highbank_mc_edac.c b/drivers/edac/highbank_mc_edac.c
index 11260cc3360e..0e7e0a404d89 100644
--- a/drivers/edac/highbank_mc_edac.c
+++ b/drivers/edac/highbank_mc_edac.c
@@ -22,7 +22,6 @@
#include <linux/of_platform.h>
#include <linux/uaccess.h>
-#include "edac_core.h"
#include "edac_module.h"
/* DDR Ctrlr Error Registers */
diff --git a/drivers/edac/i3000_edac.c b/drivers/edac/i3000_edac.c
index 5cb36a6022cc..5306240570d7 100644
--- a/drivers/edac/i3000_edac.c
+++ b/drivers/edac/i3000_edac.c
@@ -14,7 +14,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define I3000_REVISION "1.1"
diff --git a/drivers/edac/i3200_edac.c b/drivers/edac/i3200_edac.c
index 1f453382258a..77c58d201a30 100644
--- a/drivers/edac/i3200_edac.c
+++ b/drivers/edac/i3200_edac.c
@@ -13,7 +13,7 @@
#include <linux/pci_ids.h>
#include <linux/edac.h>
#include <linux/io.h>
-#include "edac_core.h"
+#include "edac_module.h"
#include <linux/io-64-nonatomic-lo-hi.h>
diff --git a/drivers/edac/i5000_edac.c b/drivers/edac/i5000_edac.c
index 72e07e3cf718..1670d27bcac8 100644
--- a/drivers/edac/i5000_edac.c
+++ b/drivers/edac/i5000_edac.c
@@ -22,7 +22,7 @@
#include <linux/edac.h>
#include <asm/mmzone.h>
-#include "edac_core.h"
+#include "edac_module.h"
/*
* Alter this version for the I5000 module when modifications are made
diff --git a/drivers/edac/i5100_edac.c b/drivers/edac/i5100_edac.c
index c655162caf08..a8334c4acea7 100644
--- a/drivers/edac/i5100_edac.c
+++ b/drivers/edac/i5100_edac.c
@@ -29,7 +29,6 @@
#include <linux/mmzone.h>
#include <linux/debugfs.h>
-#include "edac_core.h"
#include "edac_module.h"
/* register addresses */
diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index 6ef6ad1ba16e..abf6ef22e220 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -32,7 +32,7 @@
#include <linux/edac.h>
#include <linux/mmzone.h>
-#include "edac_core.h"
+#include "edac_module.h"
/*
* Alter this version for the I5400 module when modifications are made
diff --git a/drivers/edac/i7300_edac.c b/drivers/edac/i7300_edac.c
index dcac982fdc7a..0a912bf6de00 100644
--- a/drivers/edac/i7300_edac.c
+++ b/drivers/edac/i7300_edac.c
@@ -26,7 +26,7 @@
#include <linux/edac.h>
#include <linux/mmzone.h>
-#include "edac_core.h"
+#include "edac_module.h"
/*
* Alter this version for the I7300 module when modifications are made
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 8a68a5e943ea..69b5adead0ad 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -39,7 +39,7 @@
#include <asm/processor.h>
#include <asm/div64.h>
-#include "edac_core.h"
+#include "edac_module.h"
/* Static vars */
static LIST_HEAD(i7core_edac_list);
diff --git a/drivers/edac/i82443bxgx_edac.c b/drivers/edac/i82443bxgx_edac.c
index 4d4110364f02..cb61a5b7d080 100644
--- a/drivers/edac/i82443bxgx_edac.c
+++ b/drivers/edac/i82443bxgx_edac.c
@@ -29,7 +29,7 @@
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define I82443_REVISION "0.1"
diff --git a/drivers/edac/i82860_edac.c b/drivers/edac/i82860_edac.c
index ee1078cd3b96..236c813227fc 100644
--- a/drivers/edac/i82860_edac.c
+++ b/drivers/edac/i82860_edac.c
@@ -14,7 +14,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define I82860_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "i82860_edac"
diff --git a/drivers/edac/i82875p_edac.c b/drivers/edac/i82875p_edac.c
index c26a513f8869..e286b7e74c7a 100644
--- a/drivers/edac/i82875p_edac.c
+++ b/drivers/edac/i82875p_edac.c
@@ -18,7 +18,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define I82875P_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "i82875p_edac"
diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c
index 35ab66c623a3..7baa8ace267b 100644
--- a/drivers/edac/i82975x_edac.c
+++ b/drivers/edac/i82975x_edac.c
@@ -14,7 +14,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define I82975X_REVISION " Ver: 1.0.0"
#define EDAC_MOD_STR "i82975x_edac"
diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c
index 1c88d9707495..2733fb5938a4 100644
--- a/drivers/edac/ie31200_edac.c
+++ b/drivers/edac/ie31200_edac.c
@@ -41,7 +41,7 @@
#include <linux/edac.h>
#include <linux/io-64-nonatomic-lo-hi.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define IE31200_REVISION "1.0"
#define EDAC_MOD_STR "ie31200_edac"
diff --git a/drivers/edac/layerscape_edac.c b/drivers/edac/layerscape_edac.c
index 6c59d897ad12..94cac7686a56 100644
--- a/drivers/edac/layerscape_edac.c
+++ b/drivers/edac/layerscape_edac.c
@@ -16,7 +16,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include "edac_core.h"
+#include "edac_module.h"
#include "fsl_ddr_edac.h"
static const struct of_device_id fsl_ddr_mc_err_of_match[] = {
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index ff0567526ee3..ab51ce0aae0a 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -25,7 +25,6 @@
#include <linux/of_platform.h>
#include <linux/of_device.h>
#include "edac_module.h"
-#include "edac_core.h"
#include "mpc85xx_edac.h"
#include "fsl_ddr_edac.h"
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index cb9b8577acbc..14b7e7b71eaa 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -17,7 +17,6 @@
#include <linux/edac.h>
#include <linux/gfp.h>
-#include "edac_core.h"
#include "edac_module.h"
#include "mv64x60_edac.h"
diff --git a/drivers/edac/octeon_edac-l2c.c b/drivers/edac/octeon_edac-l2c.c
index afea7fc625cc..c33059e9b0be 100644
--- a/drivers/edac/octeon_edac-l2c.c
+++ b/drivers/edac/octeon_edac-l2c.c
@@ -16,7 +16,6 @@
#include <asm/octeon/cvmx.h>
-#include "edac_core.h"
#include "edac_module.h"
#define EDAC_MOD_STR "octeon-l2c"
diff --git a/drivers/edac/octeon_edac-lmc.c b/drivers/edac/octeon_edac-lmc.c
index cda6dab5067a..9c1ffe3e912b 100644
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -19,7 +19,6 @@
#include <asm/octeon/octeon.h>
#include <asm/octeon/cvmx-lmcx-defs.h>
-#include "edac_core.h"
#include "edac_module.h"
#define OCTEON_MAX_MC 4
diff --git a/drivers/edac/octeon_edac-pc.c b/drivers/edac/octeon_edac-pc.c
index 2ab6cf24c959..754eced59c32 100644
--- a/drivers/edac/octeon_edac-pc.c
+++ b/drivers/edac/octeon_edac-pc.c
@@ -15,7 +15,6 @@
#include <linux/io.h>
#include <linux/edac.h>
-#include "edac_core.h"
#include "edac_module.h"
#include <asm/octeon/cvmx.h>
diff --git a/drivers/edac/octeon_edac-pci.c b/drivers/edac/octeon_edac-pci.c
index 9ca73cec74e7..28b238eecefc 100644
--- a/drivers/edac/octeon_edac-pci.c
+++ b/drivers/edac/octeon_edac-pci.c
@@ -18,7 +18,6 @@
#include <asm/octeon/cvmx-pci-defs.h>
#include <asm/octeon/octeon.h>
-#include "edac_core.h"
#include "edac_module.h"
static void octeon_pci_poll(struct edac_pci_ctl_info *pci)
diff --git a/drivers/edac/pasemi_edac.c b/drivers/edac/pasemi_edac.c
index 9c971b575530..199f2c80480d 100644
--- a/drivers/edac/pasemi_edac.c
+++ b/drivers/edac/pasemi_edac.c
@@ -26,7 +26,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define MODULE_NAME "pasemi_edac"
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index 691ce25e9010..e55e92590106 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -21,7 +21,7 @@
#include <asm/dcr.h>
-#include "edac_core.h"
+#include "edac_module.h"
#include "ppc4xx_edac.h"
/*
diff --git a/drivers/edac/r82600_edac.c b/drivers/edac/r82600_edac.c
index 8f936bc7a010..978916625ced 100644
--- a/drivers/edac/r82600_edac.c
+++ b/drivers/edac/r82600_edac.c
@@ -20,7 +20,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/edac.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define R82600_REVISION " Ver: 2.0.2"
#define EDAC_MOD_STR "r82600_edac"
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index 54775221a01f..2d4256bb2ac6 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -26,7 +26,7 @@
#include <asm/processor.h>
#include <asm/mce.h>
-#include "edac_core.h"
+#include "edac_module.h"
/* Static vars */
static LIST_HEAD(sbridge_edac_list);
diff --git a/drivers/edac/skx_edac.c b/drivers/edac/skx_edac.c
index 0ff4878c2aa1..db46514e4c13 100644
--- a/drivers/edac/skx_edac.c
+++ b/drivers/edac/skx_edac.c
@@ -28,7 +28,7 @@
#include <asm/processor.h>
#include <asm/mce.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define SKX_REVISION " Ver: 1.0 "
diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
index fc153aea2f6c..1c01dec78ec3 100644
--- a/drivers/edac/synopsys_edac.c
+++ b/drivers/edac/synopsys_edac.c
@@ -23,7 +23,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include "edac_core.h"
+#include "edac_module.h"
/* Number of cs_rows needed per memory controller */
#define SYNPS_EDAC_NR_CSROWS 1
diff --git a/drivers/edac/tile_edac.c b/drivers/edac/tile_edac.c
index 71381642ce2a..8a33a87e67f1 100644
--- a/drivers/edac/tile_edac.c
+++ b/drivers/edac/tile_edac.c
@@ -30,7 +30,7 @@
#include <hv/hypervisor.h>
#include <hv/drv_mshim_intf.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define DRV_NAME "tile-edac"
diff --git a/drivers/edac/x38_edac.c b/drivers/edac/x38_edac.c
index 314cf5cf268c..03c97a4bf590 100644
--- a/drivers/edac/x38_edac.c
+++ b/drivers/edac/x38_edac.c
@@ -16,7 +16,7 @@
#include <linux/edac.h>
#include <linux/io-64-nonatomic-lo-hi.h>
-#include "edac_core.h"
+#include "edac_module.h"
#define X38_REVISION "1.1"
diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
index bf19b6e3bd12..54acb8fcb2fc 100644
--- a/drivers/edac/xgene_edac.c
+++ b/drivers/edac/xgene_edac.c
@@ -28,7 +28,6 @@
#include <linux/of_address.h>
#include <linux/regmap.h>
-#include "edac_core.h"
#include "edac_module.h"
#define EDAC_MOD_STR "xgene_edac"
--
2.7.4
^ permalink raw reply related
* [PATCH v4 6/8] dt-bindings: Add support for Amlogic GXBB SCPI Interface
From: Olof Johansson @ 2016-10-29 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475652814-30619-7-git-send-email-narmstrong@baylibre.com>
Hi,
On Wed, Oct 5, 2016 at 12:33 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index faa4b44..04bc171 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,7 @@ by Linux to initiate various system control and power operations.
>
> Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be "arm,scpi" or "amlogic,meson-gxbb-scpi"
This doesn't seem right to document here. If anything you might want
to have a table of more-specific-compatibles for specific
implementations, but "arm,scpi" should still be the compatible of the
node (just not the most specific one).
Also, documenting it here indiciates that non-amlogic implementations
can/should use that compatible, which is misleading.
> - mboxes: List of phandle and mailbox channel specifiers
> All the channels reserved by remote SCP firmware for use by
> SCPI message protocol should be specified in any order
> @@ -60,7 +60,8 @@ A small area of SRAM is reserved for SCPI communication between application
> processors and SCP.
>
> Required properties:
> -- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
> +- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno,
> + or "amlogic,meson-gxbb-sram" for Amlogic GXBB SoC.
Maybe you'd be better of with a meson-specific document that refers to
these but with different compatible values.
Come to think of it, the Juno-specific one maybe shouldn't be in
arm,scpi at all, since that adds confusion here.
It's somewhat confusing that ARM is both a platform, architecture and
in some cases implementer of specific systems. :)
> The rest of the properties should follow the generic mmio-sram description
> found in ../../sram/sram.txt
> @@ -70,7 +71,8 @@ Each sub-node represents the reserved area for SCPI.
> Required sub-node properties:
> - reg : The base offset and size of the reserved area with the SRAM
> - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
> - shared memory on Juno platforms
> + shared memory on Juno platforms or
> + "amlogic,meson-gxbb-scp-shmem" for Amlogic GXBB SoC.
Same here. It won't scale if all vendors are expected to add an entry here.
-Olof
^ permalink raw reply
* [GIT PULL] firmware: SCPI updates for v4.10
From: Olof Johansson @ 2016-10-29 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028112920.GB12241@e107155-lin>
Hi Sudeep,
On Fri, Oct 28, 2016 at 12:29:20PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC Team,
>
> Please pull !
>
> --
> Regards,
> Sudeep
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scpi-updates-4.10
>
> for you to fetch changes up to a9e0192d8b35c6ab115a154ed1499ff39a0e5b06:
>
> firmware: arm_scpi: add support for legacy match table on Amlogic GXBB SoC (2016-10-19 15:17:28 +0100)
>
> ----------------------------------------------------------------
> SCPI updates for v4.10
>
> 1. Adds support for Legacy SCPI(pre- SCPI v1.0) protocol
>
> 2. Adds support for SCPI used on Amlogic GXBB SoC using the legacy
> SCPI protocol
>
> ----------------------------------------------------------------
> Neil Armstrong (5):
> dt-bindings: Add support for Amlogic GXBB SCPI Interface
I had comments on this patch, just emailed as follow-up to it.
Also, you didn't sign off on it when applying it, seems like a mistake.
Please respin, ideally with the other changes also done (i.e. splitting off
Juno stuff from arm,scpi.txt).
-Olof
^ permalink raw reply
* [GIT PULL] ARM: vexpress: fixes for v4.10
From: Olof Johansson @ 2016-10-29 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028113003.GC12241@e107155-lin>
On Fri, Oct 28, 2016 at 12:30:03PM +0100, Sudeep Holla wrote:
> Hi ARM SoC team,
>
> These couple of fixes help to boot TC2 in HYP mode with CONFIG_MCPM
> enabled. This was not supported directly before and hence targeting for
> v4.10. Currently those who want to boot in HYP mode have to disable
> MCPM config in the build.
>
> Please pull.
>
> --
> Regards,
> Sudeep
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-fixes-4.10
>
> for you to fetch changes up to 801f33be8e902d8cea75cb7ac056d07c4fdd25f8:
>
> drivers: cci: add missing CCI port availability firmware check (2016-10-17 14:27:54 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: fixes/updates for v4.10
From: Olof Johansson @ 2016-10-29 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028113038.GD12241@e107155-lin>
On Fri, Oct 28, 2016 at 12:30:38PM +0100, Sudeep Holla wrote:
> Hi ARM Soc Team,
>
> Please pull !
>
> --
> Regards,
> Sudeep
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-dt-4.10
>
> for you to fetch changes up to b01c3994817dc4e117c5642c3e09e0a231b5b477:
>
> ARM: dts: vexpress: add TC2 cpu capacity-dmips-mhz information (2016-10-17 17:05:58 +0100)
>
> ----------------------------------------------------------------
> ARMv7 Vexpress DT fixes/updates for v4.10
>
> 1. Addition of CPU dmips/capacity information to TC2 platform
>
> 2. Cleanup/fix unit address warnings and removal of skeleton.dtsi from
> MPS2 device tree
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v4.10
From: Olof Johansson @ 2016-10-29 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028113104.GE12241@e107155-lin>
On Fri, Oct 28, 2016 at 12:31:04PM +0100, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull.
>
> --
> Regards,
> Sudeep
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-dt-4.10
>
> for you to fetch changes up to c1ab65b24065ab04bdb0bc4e89d88784d38dc644:
>
> arm64: dts: juno: add cpu capacity-dmips-mhz information to R2 boards (2016-10-17 17:43:22 +0100)
>
> ----------------------------------------------------------------
> ARMv8 Vexpress/Juno DT updates for v4.10
>
> 1. Addition of SMMU(MMU-401) device nodes mainly to assist other
> developments and testing
>
> 2. Addition of CPU dmips/capacity information on all the Juno boards
>
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2016-10-29 18:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to b70e8beb09d313202afd9d3953f501f02ee4e44b:
Merge tag 'v4.9-rockchip-dts64-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes (2016-10-29 11:09:37 -0700)
----------------------------------------------------------------
ARM: SoC fixes
We haven't seen a whole lot of fixes for the first two weeks since the merge
window, but here is the batch that we have at the moment.
Nothing sticks out as particularly bad or scary, it's mostly a handful of
smaller fixes to several platforms. The Uniphier reset controller changes
could probably have been delayed to 4.10, but they're not scary and just
plumbing up driver changes that went in during the merge window.
We're also adding another maintainer to Marvell Berlin platforms, to help
out when Sebastian is too busy. Yay teamwork!
----------------------------------------------------------------
Fabio Estevam (3):
ARM: imx: gpc: Initialize all power domains
ARM: imx: gpc: Fix the imx_gpc_genpd_init() error path
ARM: imx: mach-imx6q: Fix the PHY ID mask for AR8031
Gregory CLEMENT (1):
ARM: mvebu: Select corediv clk for all mvebu v7 SoC
Jisheng Zhang (1):
MAINTAINERS: add myself as Marvell berlin SoC maintainer
Linus Walleij (2):
ARM: dts: fix the SD card on the Snowball
bus: qcom-ebi2: depend on ARCH_QCOM or COMPILE_TEST
Marcin Wojtas (1):
arm64: dts: marvell: fix clocksource for CP110 master SPI0
Masahiro Yamada (5):
ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER
reset: uniphier: rename MIO reset to SD reset for Pro5, PXs2, LD20 SoCs
ARM: dts: uniphier: change MIO node to SD control node
arm64: dts: uniphier: change MIO node to SD control node
Olof Johansson (5):
Merge tag 'mvebu-fixes-4.8-3' of git://git.infradead.org/linux-mvebu into fixes
Merge tag 'uniphier-fixes-v4.9' of git://git.kernel.org/.../masahiroy/linux-uniphier into fixes
Merge tag 'imx-fixes-4.9' of git://git.kernel.org/.../shawnguo/linux into fixes
Merge tag 'arm-soc/for-4.9/devicetree-arm64-fixes' of http://github.com/Broadcom/stblinux into fixes
Merge tag 'v4.9-rockchip-dts64-fixes1' of git://git.kernel.org/.../mmind/linux-rockchip into fixes
Ray Jui (1):
arm64: dts: Updated NAND DT properties for NS2 SVK
Scott Branden (1):
ARM: multi_v7_defconfig: Enable Intel e1000e driver
Scott Wood (1):
arm64: dts: Add timer erratum property for LS2080A and LS1043A
Shawn Lin (2):
arm64: dts: rockchip: remove always-on and boot-on from vcc_sd
arm64: dts: rockchip: remove the abuse of keep-power-in-suspend
Stefan Agner (1):
ARM: dts: vf610: fix IRQ flag of global timer
.../devicetree/bindings/reset/uniphier-reset.txt | 62 +++++++++++-----------
MAINTAINERS | 1 +
arch/arm/boot/dts/ste-snowball.dts | 15 +++++-
arch/arm/boot/dts/uniphier-pro5.dtsi | 4 +-
arch/arm/boot/dts/uniphier-pxs2.dtsi | 4 +-
arch/arm/boot/dts/vf500.dtsi | 2 +-
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-imx/gpc.c | 15 ++++--
arch/arm/mach-imx/mach-imx6q.c | 2 +-
arch/arm/mach-mvebu/Kconfig | 4 +-
arch/arm/mach-uniphier/Kconfig | 1 +
arch/arm64/Kconfig.platforms | 1 +
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 2 +
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
.../boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 3 --
.../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 4 --
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 12 ++---
drivers/bus/Kconfig | 1 +
drivers/reset/reset-uniphier.c | 16 +++---
21 files changed, 87 insertions(+), 67 deletions(-)
^ permalink raw reply
* [PATCH 0/3] Support userspace irqchip with arch timers
From: Alexander Graf @ 2016-10-29 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1154342410.9324183.1477747141878.JavaMail.zimbra@redhat.com>
> On 29 Oct 2016, at 15:19, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>>>>> What the status of userspace for this thing? Are QEMU patches being
>>>>> posted and reviewed?
>>>>
>>>> I didn't see a notification that the patches were merged. Are they in
>>>> Linus' tree yet? Then I can post enablement to qemu-devel.
>>>
>>> I think you got it backward. I have no intention of merging them until I
>>> see a vague consensus on the userspace API, and a set of patches ready
>>> to be merged in QEMU.
>>
>> That's not how kvm apis are made.
>
> Actually I think it's always been like this, depending on what Marc meant for
> "ready to be merged in QEMU". It doesn't make sense to merge KVM APIs without
> having userspace patches at least posted as RFC to qemu-devel, and without
> having at least a positive response from the QEMU architecture maintainer.
I halfway agree. I do agree that there needs to be a reference implementation that proves the API to make sense. That bit is referenced in the cover letter of the patch set.
Peter as the QEMU architecture maintainer has been part of the review process and involved from the beginning. In fact, the current approach was his idea.
Do we need to fly the loop over qemu-devel? I doubt it, but if it makes you happy I can post an RFC there too.
> ARM does require a bit more care because there's no overlap between kernel
> and userspace maintainers, so perhaps that's the source of the confusion?
>
> Now, of course merging the patches in QEMU may take a month or two depending
> on the timing (because you have to wait for the patches to be merged into
> Linus's tree and for the KVM headers to be updated in QEMU---which is not
> going to happen during freeze of course). So of course the KVM patch thus
> can be committed even if QEMU is in freeze, as long as the QEMU architecture
> maintainer gives an overall green light.
Right. My plan was to make sure that people agree on the KVM interface. Then directly send non-RFC patches to qemu-devel, which can only happen when the KVM patches are merged. I didn?t see any reason why that approach would be controversial, since everyone who really cared was involved.
But again, I don?t care strongly enough to make a fuss. If people are happier with RFC patches on the ML rather than a github link to RFC patches, I?ll send them.
Alex
^ permalink raw reply
* [PATCH 00/15] use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-10-29 19:36 UTC (permalink / raw)
To: linux-arm-kernel
Use DEVICE_ATTR_RO etc. for read only attributes etc. This simplifies the
source code, improves readbility, and reduces the chance of
inconsistencies.
The complete semantic patch is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@ro@
declarer name DEVICE_ATTR;
identifier x,x_show;
@@
DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL);
@wo@
declarer name DEVICE_ATTR;
identifier x,x_store;
@@
DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store);
@rw@
declarer name DEVICE_ATTR;
identifier x,x_show,x_store;
@@
DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
@script:ocaml@
x << ro.x;
x_show << ro.x_show;
@@
if not (x^"_show" = x_show) then Coccilib.include_match false
@script:ocaml@
x << wo.x;
x_store << wo.x_store;
@@
if not (x^"_store" = x_store) then Coccilib.include_match false
@script:ocaml@
x << rw.x;
x_show << rw.x_show;
x_store << rw.x_store;
@@
if not (x^"_show" = x_show && x^"_store" = x_store)
then Coccilib.include_match false
@@
declarer name DEVICE_ATTR_RO;
identifier ro.x,ro.x_show;
@@
- DEVICE_ATTR(x, \(0444\|S_IRUGO\), x_show, NULL);
+ DEVICE_ATTR_RO(x);
@@
declarer name DEVICE_ATTR_WO;
identifier wo.x,wo.x_store;
@@
- DEVICE_ATTR(x, \(0200\|S_IWUSR\), NULL, x_store);
+ DEVICE_ATTR_WO(x);
@@
declarer name DEVICE_ATTR_RW;
identifier rw.x,rw.x_show,rw.x_store;
@@
- DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
+ DEVICE_ATTR_RW(x);
// </smpl>
---
arch/mips/txx9/generic/7segled.c | 4 ++--
arch/powerpc/kernel/iommu.c | 3 +--
arch/tile/kernel/sysfs.c | 14 +++++++-------
drivers/atm/solos-pci.c | 2 +-
drivers/pci/pcie/aspm.c | 4 ++--
drivers/power/supply/wm8350_power.c | 2 +-
drivers/ptp/ptp_sysfs.c | 2 +-
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
drivers/thermal/thermal_hwmon.c | 2 +-
drivers/tty/nozomi.c | 4 ++--
drivers/usb/wusbcore/dev-sysfs.c | 6 +++---
drivers/usb/wusbcore/wusbhc.c | 13 +++++--------
drivers/video/fbdev/wm8505fb.c | 2 +-
sound/soc/omap/mcbsp.c | 4 ++--
sound/soc/soc-dapm.c | 2 +-
15 files changed, 31 insertions(+), 35 deletions(-)
^ permalink raw reply
* [PATCH 04/15] video: fbdev: use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-10-29 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477769829-22230-1-git-send-email-Julia.Lawall@lip6.fr>
Use DEVICE_ATTR_RW for read-write attributes. This simplifies the
source code, improves readbility, and reduces the chance of
inconsistencies.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@rw@
declarer name DEVICE_ATTR;
identifier x,x_show,x_store;
@@
DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
@script:ocaml@
x << rw.x;
x_show << rw.x_show;
x_store << rw.x_store;
@@
if not (x^"_show" = x_show && x^"_store" = x_store)
then Coccilib.include_match false
@@
declarer name DEVICE_ATTR_RW;
identifier rw.x,rw.x_show,rw.x_store;
@@
- DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
+ DEVICE_ATTR_RW(x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/wm8505fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index e925619..253ffe9 100644
--- a/drivers/video/fbdev/wm8505fb.c
+++ b/drivers/video/fbdev/wm8505fb.c
@@ -182,7 +182,7 @@ static ssize_t contrast_store(struct device *dev,
return count;
}
-static DEVICE_ATTR(contrast, 0644, contrast_show, contrast_store);
+static DEVICE_ATTR_RW(contrast);
static inline u_int chan_to_field(u_int chan, struct fb_bitfield *bf)
{
^ permalink raw reply related
* [PATCH v2] ARM: pxa: em-x270: use the new pxa_camera platform_data
From: Robert Jarzmik @ 2016-10-29 19:39 UTC (permalink / raw)
To: linux-arm-kernel
pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: add regulator platform_device and missing include
---
arch/arm/mach-pxa/em-x270.c | 89 +++++++++++++++------------------------------
1 file changed, 29 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 03354c21e1f2..811a7317f3ea 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -23,6 +23,7 @@
#include <linux/gpio.h>
#include <linux/mfd/da903x.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <linux/spi/spi.h>
#include <linux/spi/tdo24m.h>
#include <linux/spi/libertas_spi.h>
@@ -34,8 +35,6 @@
#include <linux/i2c/pxa-i2c.h>
#include <linux/regulator/userspace-consumer.h>
-#include <media/soc_camera.h>
-
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -958,8 +957,6 @@ static inline void em_x270_init_gpio_keys(void) {}
/* Quick Capture Interface and sensor setup */
#if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
-static struct regulator *em_x270_camera_ldo;
-
static int em_x270_sensor_init(void)
{
int ret;
@@ -969,81 +966,53 @@ static int em_x270_sensor_init(void)
return ret;
gpio_direction_output(cam_reset, 0);
-
- em_x270_camera_ldo = regulator_get(NULL, "vcc cam");
- if (em_x270_camera_ldo == NULL) {
- gpio_free(cam_reset);
- return -ENODEV;
- }
-
- ret = regulator_enable(em_x270_camera_ldo);
- if (ret) {
- regulator_put(em_x270_camera_ldo);
- gpio_free(cam_reset);
- return ret;
- }
-
gpio_set_value(cam_reset, 1);
return 0;
}
-struct pxacamera_platform_data em_x270_camera_platform_data = {
- .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
- .mclk_10khz = 2600,
+static struct regulator_consumer_supply camera_dummy_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "0-005d"),
};
-static int em_x270_sensor_power(struct device *dev, int on)
-{
- int ret;
- int is_on = regulator_is_enabled(em_x270_camera_ldo);
-
- if (on == is_on)
- return 0;
-
- gpio_set_value(cam_reset, !on);
-
- if (on)
- ret = regulator_enable(em_x270_camera_ldo);
- else
- ret = regulator_disable(em_x270_camera_ldo);
-
- if (ret)
- return ret;
-
- gpio_set_value(cam_reset, on);
-
- return 0;
-}
-
-static struct i2c_board_info em_x270_i2c_cam_info[] = {
- {
- I2C_BOARD_INFO("mt9m111", 0x48),
+static struct regulator_init_data camera_dummy_initdata = {
+ .consumer_supplies = camera_dummy_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(camera_dummy_supplies),
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
},
};
-static struct soc_camera_link iclink = {
- .bus_id = 0,
- .power = em_x270_sensor_power,
- .board_info = &em_x270_i2c_cam_info[0],
- .i2c_adapter_id = 0,
+static struct fixed_voltage_config camera_dummy_config = {
+ .supply_name = "camera_vdd",
+ .input_supply = "vcc cam",
+ .microvolts = 2800000,
+ .gpio = -1,
+ .enable_high = 0,
+ .init_data = &camera_dummy_initdata,
};
-static struct platform_device em_x270_camera = {
- .name = "soc-camera-pdrv",
- .id = -1,
+static struct platform_device camera_supply_dummy_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
.dev = {
- .platform_data = &iclink,
+ .platform_data = &camera_dummy_config,
},
};
+struct pxacamera_platform_data em_x270_camera_platform_data = {
+ .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ .mclk_10khz = 2600,
+ .sensor_i2c_adapter_id = 0,
+ .sensor_i2c_address = 0x5d,
+};
+
static void __init em_x270_init_camera(void)
{
- if (em_x270_sensor_init() == 0) {
+ if (em_x270_sensor_init() == 0)
pxa_set_camera_info(&em_x270_camera_platform_data);
- platform_device_register(&em_x270_camera);
- }
+ platform_device_register(&camera_supply_dummy_device);
}
#else
static inline void em_x270_init_camera(void) {}
--
2.1.4
^ permalink raw reply related
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Arnd Bergmann @ 2016-10-29 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477138444-14993-1-git-send-email-ynorov@caviumnetworks.com>
On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> unistd.h prior to including asm-generic/unistd.h, and adjust all
> architectures using the generic syscall list to define it so that no
> in-tree architectures are affected.
The patch looks good, but shouldn't we also hide the actual syscall
implementation if the symbol is not set? It's just dead code otherwise
for new architectures.
Arnd
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-10-29 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUwS=F-803_i=Zour+jo1T43KFO=t53XgcPBeiuF7e7DQ@mail.gmail.com>
On Saturday, October 22, 2016 9:44:11 AM CEST Geert Uytterhoeven wrote:
> Hi Arnd,
>
> On Fri, Oct 21, 2016 at 11:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday, October 21, 2016 8:16:00 PM CEST Geert Uytterhoeven wrote:
> >> On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > 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:
> >> > I'd prefer seeing a separate soc driver for that one.
> >> >> 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?
> >>
> >> Unfortunately there exist SoCs from different families using the same
> >> product ID.
> >>
> >> And different SoCs from the same family may have a revision register
> >> or not (e.g. R-Car H1 has, M1A hasn't).
> >
> > Is this something we expect to see more of in the future, or can
> > we expect future chips to handle this more consistently?
>
> I expect to see more of these in the future.
>
> Perhaps I just should forget about the product IDs and (marketing) families,
> and just stick the CCCR/PRR addresses in the of_device_ids?
> Then we'll have SoC names (e.g. "r8a7791") and (optional) revisions
> (e.g. "ES1.0") to match on.
I don't think listing the marketing names is a problem if we need a
full list of all chips in of_device_ids anyway.
I'm still hoping to be able to limit the need for specifying the
register addresses in the driver instead.
> >> > 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.
> >>
> >> Hmm... That means that if we have to add a driver quirk to distinguish
> >> between different revisions of the same SoC, we have to update the
> >> DTB anyway, to add the CCCR/PRR device node.
> >> We might as well just change the compatible value in that DTB for the
> >> device that needs the quirk. Which is what we'd like to avoid in the
> >> first place.
> >
> > Do you have a specific example in mind? If this is only a theoretical
> > problem, we can worry about it when we get there, and then decide
> > if we add a hardcoded register after all.
>
> For R-Car H3, there are small differences between ES1.0 and ES1.1,
> and more and larger differences between ES1.x and ES2.0, which
> need different handling (patches already floating around).
>
> For (old) R-Car H1, the SATA driver already handles "renesas,sata-r8a7790-es1",
> but so far there didn't exist an established process to specify how that
> compatible value would end up in the DTB (the in-kernel DTS doesn't have it).
>
> There may be more differences I'm not aware of.
Ok, so for R-Car H1, I assume we don't need the driver, it would just
be a way to replace the current workaround with a different one, right?
For R-Car H3, do we just require driver changes to work with ES2.0,
or also DT changes? If the new chip version already implies a new DT,
we can require the presence of a device node that has the correct
register number.
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: r8a7794: remove Z clock
From: Sergei Shtylyov @ 2016-10-29 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529351.Fac5N2tKoF@wasted.cogentembedded.com>
R8A7794 doesn't have Cortex-A15 CPUs, thus there's no Z clock...
Fixes: 0dce5454d5c2 ("ARM: shmobile: Initial r8a7794 SoC device tree")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the 'master' branch of Simon Horman's 'renesas.git' repo.
arch/arm/boot/dts/r8a7794.dtsi | 3 +--
include/dt-bindings/clock/r8a7794-clock.h | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1025,8 +1025,7 @@
clocks = <&extal_clk &usb_extal_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll3",
- "lb", "qspi", "sdh", "sd0", "z",
- "rcan";
+ "lb", "qspi", "sdh", "sd0", "rcan";
#power-domain-cells = <0>;
};
/* Variable factor clocks */
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -20,8 +20,7 @@
#define R8A7794_CLK_QSPI 5
#define R8A7794_CLK_SDH 6
#define R8A7794_CLK_SD0 7
-#define R8A7794_CLK_Z 8
-#define R8A7794_CLK_RCAN 9
+#define R8A7794_CLK_RCAN 8
/* MSTP0 */
#define R8A7794_CLK_MSIOF0 0
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Yury Norov @ 2016-10-29 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2502005.4risrb1P1I@wuerfel>
On Sat, Oct 29, 2016 at 11:02:40PM +0200, Arnd Bergmann wrote:
> On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> > The newer prlimit64 syscall provides all the functionality provided by
> > the getrlimit and setrlimit syscalls and adds the pid of target process,
> > so future architectures won't need to include getrlimit and setrlimit.
> >
> > Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> > list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> > unistd.h prior to including asm-generic/unistd.h, and adjust all
> > architectures using the generic syscall list to define it so that no
> > in-tree architectures are affected.
>
> The patch looks good, but shouldn't we also hide the actual syscall
> implementation if the symbol is not set? It's just dead code otherwise
> for new architectures.
I was thinking on it. The patch of James Hogan, b0da6d4415 (asm-generic:
Drop renameat syscall from default list) doesn't do it for renameat(), so
I decided not to do it too. It's not so easy to disable syscalls because arch
may support few ABIs, and some of them may require the syscall. For example,
arm64 supports lp64, aarch32 and ilp32, and first two ABIs need renameat()
and getrlimit/setrlimit.
At now there's no arches that doesn't need renameat() and getrlimit/setrlimit,
and there will be no such arch in nearest future. So there will be no
dead code.
But I agree with you that we need make that implementations
conditional. If I understand it correctly, we need something like
__ARCH_WANT_SET_GET_RLIMIT in all existing Kconfigs, correct?
I think this patch may be applied as is, and if needed I can send
another patch that disables renameat() and getrlimit/setrlimit soon.
James, what do you think?
Yury.
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Arnd Bergmann @ 2016-10-29 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029214541.GA20037@yury-N73SV>
On Sunday, October 30, 2016 12:45:41 AM CEST Yury Norov wrote:
> On Sat, Oct 29, 2016 at 11:02:40PM +0200, Arnd Bergmann wrote:
> > On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> > > The newer prlimit64 syscall provides all the functionality provided by
> > > the getrlimit and setrlimit syscalls and adds the pid of target process,
> > > so future architectures won't need to include getrlimit and setrlimit.
> > >
> > > Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> > > list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> > > unistd.h prior to including asm-generic/unistd.h, and adjust all
> > > architectures using the generic syscall list to define it so that no
> > > in-tree architectures are affected.
> >
> > The patch looks good, but shouldn't we also hide the actual syscall
> > implementation if the symbol is not set? It's just dead code otherwise
> > for new architectures.
>
> I was thinking on it. The patch of James Hogan, b0da6d4415 (asm-generic:
> Drop renameat syscall from default list) doesn't do it for renameat(), so
> I decided not to do it too. It's not so easy to disable syscalls because arch
> may support few ABIs, and some of them may require the syscall. For example,
> arm64 supports lp64, aarch32 and ilp32, and first two ABIs need renameat()
> and getrlimit/setrlimit.
>
> At now there's no arches that doesn't need renameat() and getrlimit/setrlimit,
> and there will be no such arch in nearest future. So there will be no
> dead code.
>
> But I agree with you that we need make that implementations
> conditional. If I understand it correctly, we need something like
> __ARCH_WANT_SET_GET_RLIMIT in all existing Kconfigs, correct?
>
> I think this patch may be applied as is, and if needed I can send
> another patch that disables renameat() and getrlimit/setrlimit soon.
Fair enough. Actually now that I think about it, there are probably
lots of other syscalls that are unused on modern architectures.
It would be good to go through the full list and hide all the ones
that are not referenced, but that is clearly independent of your
patch.
Arnd
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Arnd Bergmann @ 2016-10-29 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477138444-14993-1-git-send-email-ynorov@caviumnetworks.com>
On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> The newer prlimit64 syscall provides all the functionality provided by
> the getrlimit and setrlimit syscalls and adds the pid of target process,
> so future architectures won't need to include getrlimit and setrlimit.
>
> Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> unistd.h prior to including asm-generic/unistd.h, and adjust all
> architectures using the generic syscall list to define it so that no
> in-tree architectures are affected.
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Can you include this patch in your ilp32 series?
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: Yury Norov @ 2016-10-29 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5823871.3DMLUx5Xtp@wuerfel>
On Sat, Oct 29, 2016 at 11:54:08PM +0200, Arnd Bergmann wrote:
> On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
> > The newer prlimit64 syscall provides all the functionality provided by
> > the getrlimit and setrlimit syscalls and adds the pid of target process,
> > so future architectures won't need to include getrlimit and setrlimit.
> >
> > Therefore drop getrlimit and setrlimit syscalls from the generic syscall
> > list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
> > unistd.h prior to including asm-generic/unistd.h, and adjust all
> > architectures using the generic syscall list to define it so that no
> > in-tree architectures are affected.
> >
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Can you include this patch in your ilp32 series?
Already did.
https://github.com/norov/linux/commits/ilp32-4.9
^ permalink raw reply
* [PATCH] asm-generic: Drop getrlimit and setrlimit syscalls from default list
From: James Hogan @ 2016-10-29 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029214541.GA20037@yury-N73SV>
On 29 October 2016 22:45:41 BST, Yury Norov <ynorov@caviumnetworks.com> wrote:
>On Sat, Oct 29, 2016 at 11:02:40PM +0200, Arnd Bergmann wrote:
>> On Saturday, October 22, 2016 3:14:04 PM CEST Yury Norov wrote:
>> > The newer prlimit64 syscall provides all the functionality provided
>by
>> > the getrlimit and setrlimit syscalls and adds the pid of target
>process,
>> > so future architectures won't need to include getrlimit and
>setrlimit.
>> >
>> > Therefore drop getrlimit and setrlimit syscalls from the generic
>syscall
>> > list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the
>architecture's
>> > unistd.h prior to including asm-generic/unistd.h, and adjust all
>> > architectures using the generic syscall list to define it so that
>no
>> > in-tree architectures are affected.
>>
>> The patch looks good, but shouldn't we also hide the actual syscall
>> implementation if the symbol is not set? It's just dead code
>otherwise
>> for new architectures.
>
>I was thinking on it. The patch of James Hogan, b0da6d4415
>(asm-generic:
>Drop renameat syscall from default list) doesn't do it for renameat(),
>so
>I decided not to do it too. It's not so easy to disable syscalls
>because arch
>may support few ABIs, and some of them may require the syscall. For
>example,
>arm64 supports lp64, aarch32 and ilp32, and first two ABIs need
>renameat()
>and getrlimit/setrlimit.
>
>At now there's no arches that doesn't need renameat() and
>getrlimit/setrlimit,
>and there will be no such arch in nearest future. So there will be no
>dead code.
>
>But I agree with you that we need make that implementations
>conditional. If I understand it correctly, we need something like
>__ARCH_WANT_SET_GET_RLIMIT in all existing Kconfigs, correct?
>
>I think this patch may be applied as is, and if needed I can send
>another patch that disables renameat() and getrlimit/setrlimit soon.
>
>James, what do you think?
For renameat my main concern was the ABI, and I didn't think it was worth the effort or slightly increased complexity to ifdef the implementation since it was such a trivial wrapper around renameat2. Getrlimit and setrlimit aren't much more complex, just a user copy in addition to the standard doprlimit, so i probably wouldn't have bothered for them either.
cheers
James Hogan
^ 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