* [wsa:renesas/thermal-on-4.10-next 2/4] rcar_gen3_thermal.c:undefined reference to `__divdi3'
From: kbuild test robot @ 2016-12-02 8:42 UTC (permalink / raw)
To: Wolfram Sang; +Cc: kbuild-all, linux-i2c
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/thermal-on-4.10-next
head: 5c2f1bfbcb5345890559511c6a59cfca40fdc05e
commit: 00a445b11c2266cb05771ab01f691bb585e34ebb [2/4] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 00a445b11c2266cb05771ab01f691bb585e34ebb
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `rcar_gen3_thermal_get_temp':
>> rcar_gen3_thermal.c:(.text+0x2255458): undefined reference to `__divdi3'
rcar_gen3_thermal.c:(.text+0x225548a): undefined reference to `__divdi3'
drivers/built-in.o: In function `rcar_gen3_thermal_probe':
rcar_gen3_thermal.c:(.text+0x225564c): undefined reference to `__divdi3'
rcar_gen3_thermal.c:(.text+0x2255677): undefined reference to `__divdi3'
rcar_gen3_thermal.c:(.text+0x22556b7): undefined reference to `__divdi3'
drivers/built-in.o:rcar_gen3_thermal.c:(.text+0x22556e6): more undefined references to `__divdi3' follow
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56223 bytes --]
^ permalink raw reply
* Re: [PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Geert Uytterhoeven @ 2016-12-02 8:42 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <1480666227-7622-1-git-send-email-horms+renesas@verge.net.au>
On Fri, Dec 2, 2016 at 9:10 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
it's
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
is being
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
> * Add some text to describe per-SoC bindings
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-02 8:10 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree, Simon Horman
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Also:
* Deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
* Add some text to describe per-SoC bindings
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v3
* Consistently use renesas,<family>-<module> for new compat strings
* Drop RFC designation
v2
* Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..50c378ccb8e7 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
+ "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
+ "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [Patch V1] i2c: fsl-lpi2c: read lpi2c fifo size in probe()
From: Gao Pan @ 2016-12-02 3:38 UTC (permalink / raw)
To: wsa, wsa-dev, cmo, robh, vz; +Cc: linux-i2c, pandy.gao, frank.li, fugang.duan
The lpi2c fifo size is a read only parameter resides Parameter
Register. It's better to read lpi2c tx/rx fifo size in probe()
other than just define a macro for it.
Signed-off-by: Gao Pan <pandy.gao@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 9794ff6..c62b7cd 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -83,9 +83,6 @@
#define I2C_CLK_RATIO 2
#define CHUNK_DATA 256
-#define LPI2C_RX_FIFOSIZE 4
-#define LPI2C_TX_FIFOSIZE 4
-
#define LPI2C_DEFAULT_RATE 100000
#define STARDARD_MAX_BITRATE 400000
#define FAST_MAX_BITRATE 1000000
@@ -118,6 +115,8 @@ struct lpi2c_imx_struct {
unsigned int delivered;
unsigned int block_data;
unsigned int bitrate;
+ unsigned int txfifosize;
+ unsigned int rxfifosize;
enum lpi2c_imx_mode mode;
};
@@ -346,7 +345,7 @@ static int lpi2c_imx_txfifo_empty(struct lpi2c_imx_struct *lpi2c_imx)
static void lpi2c_imx_set_tx_watermark(struct lpi2c_imx_struct *lpi2c_imx)
{
- writel(LPI2C_TX_FIFOSIZE >> 1, lpi2c_imx->base + LPI2C_MFCR);
+ writel(lpi2c_imx->txfifosize >> 1, lpi2c_imx->base + LPI2C_MFCR);
}
static void lpi2c_imx_set_rx_watermark(struct lpi2c_imx_struct *lpi2c_imx)
@@ -355,8 +354,8 @@ static void lpi2c_imx_set_rx_watermark(struct lpi2c_imx_struct *lpi2c_imx)
remaining = lpi2c_imx->msglen - lpi2c_imx->delivered;
- if (remaining > (LPI2C_RX_FIFOSIZE >> 1))
- temp = LPI2C_RX_FIFOSIZE >> 1;
+ if (remaining > (lpi2c_imx->rxfifosize >> 1))
+ temp = lpi2c_imx->rxfifosize >> 1;
else
temp = 0;
@@ -369,7 +368,7 @@ static void lpi2c_imx_write_txfifo(struct lpi2c_imx_struct *lpi2c_imx)
txcnt = readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff;
- while (txcnt < LPI2C_TX_FIFOSIZE) {
+ while (txcnt < lpi2c_imx->txfifosize) {
if (lpi2c_imx->delivered == lpi2c_imx->msglen)
break;
@@ -554,6 +553,7 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
{
struct lpi2c_imx_struct *lpi2c_imx;
struct resource *res;
+ unsigned int temp;
int irq, ret;
lpi2c_imx = devm_kzalloc(&pdev->dev, sizeof(*lpi2c_imx), GFP_KERNEL);
@@ -599,12 +599,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
platform_set_drvdata(pdev, lpi2c_imx);
- ret = clk_prepare(lpi2c_imx->clk);
+ ret = clk_prepare_enable(lpi2c_imx->clk);
if (ret) {
- dev_err(&pdev->dev, "clk prepare failed %d\n", ret);
+ dev_err(&pdev->dev, "clk enable failed %d\n", ret);
return ret;
}
+ temp = readl(lpi2c_imx->base + LPI2C_PARAM);
+ lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
+ lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
+
+ clk_disable(lpi2c_imx->clk);
+
ret = i2c_add_adapter(&lpi2c_imx->adapter);
if (ret)
goto clk_unprepare;
--
1.9.1
^ permalink raw reply related
* [wsa:renesas/thermal-on-4.10-next 4/4] ERROR: "__divdi3" [drivers/thermal/rcar_gen3_thermal.ko] undefined!
From: kbuild test robot @ 2016-12-02 3:07 UTC (permalink / raw)
To: Wolfram Sang; +Cc: kbuild-all, linux-i2c
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hi Wolfram,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/thermal-on-4.10-next
head: 5c2f1bfbcb5345890559511c6a59cfca40fdc05e
commit: 5c2f1bfbcb5345890559511c6a59cfca40fdc05e [4/4] arm64: dts: r8a7796: Add R-Car Gen3 thermal support
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 5c2f1bfbcb5345890559511c6a59cfca40fdc05e
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__divdi3" [drivers/thermal/rcar_gen3_thermal.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56838 bytes --]
^ permalink raw reply
* Re: [Patch V6 2/2] i2c: imx: add low power i2c bus driver
From: Wolfram Sang @ 2016-12-01 22:45 UTC (permalink / raw)
To: Gao Pan; +Cc: wsa, cmo, robh, vz, linux-i2c, frank.li, fugang.duan
In-Reply-To: <1480473647-24514-2-git-send-email-pandy.gao@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Wed, Nov 30, 2016 at 10:40:47AM +0800, Gao Pan wrote:
> This patch adds lpi2c bus driver to support new i.MX products
> which use lpi2c instead of the old imx i2c.
>
> The lpi2c can continue operating in stop mode when an appropriate
> clock is available. It is also designed for low CPU overhead with
> DMA offloading of FIFO register accesses.
>
> Signed-off-by: Gao Pan <pandy.gao@nxp.com>
> Reviewed-by: Fugang Duan <B38611@freescale.com>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Patch V6 1/2] i2c: imx: add devicetree binding for lpi2c
From: Wolfram Sang @ 2016-12-01 22:45 UTC (permalink / raw)
To: Gao Pan; +Cc: wsa, cmo, robh, vz, linux-i2c, frank.li, fugang.duan
In-Reply-To: <1480473647-24514-1-git-send-email-pandy.gao@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
On Wed, Nov 30, 2016 at 10:40:46AM +0800, Gao Pan wrote:
> Add a binding document for lpi2c driver
>
> Signed-off-by: Gao Pan <pandy.gao@nxp.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] i2c: designware-pcidrv: Add 10bit address feature to medfield/merrifield
From: Wolfram Sang @ 2016-12-01 22:39 UTC (permalink / raw)
To: Alexander Stein
Cc: Jarkko Nikula, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
linux-i2c
In-Reply-To: <1480523655-10461-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
On Wed, Nov 30, 2016 at 05:34:15PM +0100, Alexander Stein wrote:
> Both Merrifield TRM and Medfield TRM state:
> "Both 7-bit and 10-bit addressing modes are supported."
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 3/4] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Wolfram Sang @ 2016-12-01 22:37 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <20161201110440.27530-4-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Thu, Dec 01, 2016 at 12:04:39PM +0100, Romain Perier wrote:
> The Armada 3700 has two i2c bus interface units, this commit adds the
> definitions of the corresponding device nodes. It also enables the node
> on the development board for this SoC.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This needs to go via arm-soc.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-12-01 22:36 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <20161201110440.27530-3-romain.perier@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Thu, Dec 01, 2016 at 12:04:38PM +0100, Romain Perier wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Wolfram Sang @ 2016-12-01 22:36 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <20161201110440.27530-2-romain.perier@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
On Thu, Dec 01, 2016 at 12:04:37PM +0100, Romain Perier wrote:
> So far, the bit masks for the fast and high speed mode were statically
> defined. Some IP blocks might use different bits for these modes.
>
> This commit introduces new fields in order to enable the definition of
> different bit masks for these features. If these fields are undefined,
> ICR_FM and ICR_HS are selected to preserve backward compatibility with
> other IPs.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Wolfram Sang @ 2016-12-01 22:31 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Rutland, Andrew Lunn, Wolfram Sang, Hanna Hawa, Nadav Haklai,
Neta Zur Hershkovits, linux-i2c, Yahuda Yitschak,
linux-arm-kernel, Sebastian Hesselbarth, devicetree, Jason Cooper,
Pawel Moll, Ian Campbell, Omri Itach, Rob Herring,
Gregory Clement, Marcin Wojtas, Igal Liberman, Thomas Petazzoni,
Shadi Ammouri, Kumar Gala
In-Reply-To: <20161201110440.27530-5-romain.perier@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]
On Thu, Dec 01, 2016 at 12:04:40PM +0100, Romain Perier wrote:
> This commit documents the compatible string to have the compatibility for
> the I2C unit found in the Armada 3700.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 16:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXr5stBRDtD0AE=1Af3PUiA=e5pP_X1onfbfO5ri=fPrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 01, 2016 at 04:55:13PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Dec 1, 2016 at 4:41 PM, Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> > relationship between IP blocks might be. For example, I believe that
> > r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> > descendant of the former or vice versa.
> >
> > We can, however, by examining the documentation and behaviour of the
> > hardware at run-time observe that the current driver implementation appears
> > to be compatible with the IP blocks on SoCs within a given generation.
> >
> > For the above reasons and convenience when enabling new SoCs a
> > per-generation fallback compatibility string scheme being adopted for
> > drivers for Renesas SoCs.
> >
> > Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> > compatible with R-Car Gen 1. It also appears unused in mainline.
> >
> > Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> > ---
> > Include accidently omitted i2c-rcar.c portion of patch
> > ---
> > Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
> > drivers/i2c/busses/i2c-rcar.c | 5 +++-
> > 2 files changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > index 239632a0d709..8c679b17c4c6 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > @@ -1,17 +1,25 @@
> > I2C for R-Car platforms
> >
> > Required properties:
> > -- compatible: Must be one of
> > - "renesas,i2c-rcar"
> > - "renesas,i2c-r8a7778"
> > - "renesas,i2c-r8a7779"
> > - "renesas,i2c-r8a7790"
> > - "renesas,i2c-r8a7791"
> > - "renesas,i2c-r8a7792"
> > - "renesas,i2c-r8a7793"
> > - "renesas,i2c-r8a7794"
> > - "renesas,i2c-r8a7795"
> > - "renesas,i2c-r8a7796"
> > +- compatible:
> > + "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
> > + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
> > + "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> > + "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
> > + "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
> > + "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
> > + "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
> > + "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
> > + "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> > + "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
> > + "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
> > + "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
>
> "renesas,rcar-gen1-i2c" etc.
>
> > + "renesas,i2c-rcar" (deprecated)
> > +
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first followed
> > + by the generic version.
> > +
> > - reg: physical base address of the controller and length of memory mapped
> > region.
> > - interrupts: interrupt specifier.
> > @@ -33,7 +41,7 @@ Examples :
> > i2c0: i2c@e6508000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > - compatible = "renesas,i2c-r8a7791";
> > + compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
>
> "renesas,rcar-gen2-i2c"
>
> > reg = <0 0xe6508000 0 0x40>;
> > interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
> > diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> > index 726615e54f2a..622def6b43e2 100644
> > --- a/drivers/i2c/busses/i2c-rcar.c
> > +++ b/drivers/i2c/busses/i2c-rcar.c
> > @@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
> > };
> >
> > static const struct of_device_id rcar_i2c_dt_ids[] = {
> > - { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
> > @@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
> > { .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
> > { .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
> > { .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
> > + { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
> > + { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
> > + { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
> > + { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
>
> The driver does it right ;-)
Sorry, I switched things around at some point but it looks
like I only did half the job.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
From: Jean Delvare @ 2016-12-01 16:06 UTC (permalink / raw)
To: David Howells
Cc: minyard, linux-kernel, gnomes, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
In-Reply-To: <23573.1480601572@warthog.procyon.org.uk>
On jeu., 2016-12-01 at 14:12 +0000, David Howells wrote:
> Jean Delvare <jdelvare@suse.de> wrote:
>
> > > Note that we do still need to do the module initialisation because some
> > > drivers have viable defaults set in case parameters aren't specified and
> > > some drivers support automatic configuration (e.g. PNP or PCI) in addition
> > > to manually coded parameters.
> >
> > Initializing the driver when you are not able to honor the user request
> > looks wrong to me. I don't see how some drivers having sane defaults
> > justifies that. Using the defaults when no parameters are passed is one
> > thing (good), still using the defaults when parameters are passed is
> > another (bad), and you should be able to differentiate between these two
> > cases.
>
> Corey Minyard argues the other way:
>
> This would prevent any IPMI interface from working if any address was
> given on the kernel command line. I'm not sure what the best policy
> is, but that sounds like a possible DOS to me.
>
> Your preference allows someone to prevent a driver from initialising - which
> could also be bad. The problem is that I don't think there's any way to do
> both.
I'm not sure what is your threat model, but I'm afraid that if the
attacker can change the kernel command line, he/she has so many ways to
screw up the machine, that removing one won't make a difference.
>> (...)
> > And maybe the following ones, but I'm not sure if forcibly enabling a
> > device is part of what you need to prevent:
> >
> > i2c-piix4.c:module_param (force, int, 0);
> > i2c-sis630.c:module_param(force, bool, 0);
> > i2c-viapro.c:module_param(force, bool, 0);
>
> I don't know either. One could argue it *should* be locked down because its
> need appears to reflect a BIOS bug.
Indeed. OTOH if you remove all kernel code that is there solely due to
BIOS bugs, then you can rename Secure Boot to No Boot. Well that's
certainly one way to be secure ;-)
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Geert Uytterhoeven @ 2016-12-01 15:55 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1480606863-4418-1-git-send-email-horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On Thu, Dec 1, 2016 at 4:41 PM, Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
> Include accidently omitted i2c-rcar.c portion of patch
> ---
> Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
> drivers/i2c/busses/i2c-rcar.c | 5 +++-
> 2 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> index 239632a0d709..8c679b17c4c6 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> @@ -1,17 +1,25 @@
> I2C for R-Car platforms
>
> Required properties:
> -- compatible: Must be one of
> - "renesas,i2c-rcar"
> - "renesas,i2c-r8a7778"
> - "renesas,i2c-r8a7779"
> - "renesas,i2c-r8a7790"
> - "renesas,i2c-r8a7791"
> - "renesas,i2c-r8a7792"
> - "renesas,i2c-r8a7793"
> - "renesas,i2c-r8a7794"
> - "renesas,i2c-r8a7795"
> - "renesas,i2c-r8a7796"
> +- compatible:
> + "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
> + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
> + "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> + "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
> + "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
> + "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
> + "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
> + "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
> + "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> + "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
> + "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
"renesas,rcar-gen1-i2c" etc.
> + "renesas,i2c-rcar" (deprecated)
> +
> + When compatible with the generic version, nodes must list the
> + SoC-specific version corresponding to the platform first followed
> + by the generic version.
> +
> - reg: physical base address of the controller and length of memory mapped
> region.
> - interrupts: interrupt specifier.
> @@ -33,7 +41,7 @@ Examples :
> i2c0: i2c@e6508000 {
> #address-cells = <1>;
> #size-cells = <0>;
> - compatible = "renesas,i2c-r8a7791";
> + compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
"renesas,rcar-gen2-i2c"
> reg = <0 0xe6508000 0 0x40>;
> interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index 726615e54f2a..622def6b43e2 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
> };
>
> static const struct of_device_id rcar_i2c_dt_ids[] = {
> - { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
> @@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
> { .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
> { .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
> { .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
> + { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
> + { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
> + { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
> + { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
The driver does it right ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 15:41 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree, Simon Horman
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..8c679b17c4c6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
+ "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH/RFC i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 15:32 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree
In-Reply-To: <1480605494-32460-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Dec 01, 2016 at 04:18:14PM +0100, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Sorry, I seem to have omitted the driver (C code) portion of this change.
I send v2.
^ permalink raw reply
* Re: [PATCH/RFC i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Geert Uytterhoeven @ 2016-12-01 15:26 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <1480605494-32460-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Thu, Dec 1, 2016 at 4:18 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> index 239632a0d709..8c679b17c4c6 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> @@ -1,17 +1,25 @@
> I2C for R-Car platforms
>
> Required properties:
> -- compatible: Must be one of
> - "renesas,i2c-rcar"
> - "renesas,i2c-r8a7778"
> - "renesas,i2c-r8a7779"
> - "renesas,i2c-r8a7790"
> - "renesas,i2c-r8a7791"
> - "renesas,i2c-r8a7792"
> - "renesas,i2c-r8a7793"
> - "renesas,i2c-r8a7794"
> - "renesas,i2c-r8a7795"
> - "renesas,i2c-r8a7796"
> +- compatible:
> + "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
> + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
> + "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> + "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
> + "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
> + "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
> + "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
> + "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
> + "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> + "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
> + "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
Please use "renesas,<family>-<module>" when adding family-specific
compatible values where non are defined yet.
I.e.
"renesas,rcar-gen1-i2c"
"renesas,rcar-gen1-i2c"
"renesas,rcar-gen1-i2c"
> + "renesas,i2c-rcar" (deprecated)
> +
> + When compatible with the generic version, nodes must list the
> + SoC-specific version corresponding to the platform first followed
> + by the generic version.
> +
> - reg: physical base address of the controller and length of memory mapped
> region.
> - interrupts: interrupt specifier.
> @@ -33,7 +41,7 @@ Examples :
> i2c0: i2c@e6508000 {
> #address-cells = <1>;
> #size-cells = <0>;
> - compatible = "renesas,i2c-r8a7791";
> + compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
"renesas,rcar-gen2-i2c".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 15:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Simon Horman
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..8c679b17c4c6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
+ "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
--
2.7.0.rc3.207.g0ac5344
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
From: David Howells @ 2016-12-01 14:12 UTC (permalink / raw)
To: Jean Delvare, minyard
Cc: dhowells, linux-kernel, gnomes, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
In-Reply-To: <1480600052.21573.60.camel@chaos.suse>
Jean Delvare <jdelvare@suse.de> wrote:
> > Note that we do still need to do the module initialisation because some
> > drivers have viable defaults set in case parameters aren't specified and
> > some drivers support automatic configuration (e.g. PNP or PCI) in addition
> > to manually coded parameters.
>
> Initializing the driver when you are not able to honor the user request
> looks wrong to me. I don't see how some drivers having sane defaults
> justifies that. Using the defaults when no parameters are passed is one
> thing (good), still using the defaults when parameters are passed is
> another (bad), and you should be able to differentiate between these two
> cases.
Corey Minyard argues the other way:
This would prevent any IPMI interface from working if any address was
given on the kernel command line. I'm not sure what the best policy
is, but that sounds like a possible DOS to me.
Your preference allows someone to prevent a driver from initialising - which
could also be bad. The problem is that I don't think there's any way to do
both.
Note that the policy isn't actually handled in any of these patches, but will
be handled in a later patchset that is on top of my EFI changes also.
> > Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
>
> I know this is only a Suggested-by and not a Signed-off-by, but still I
> believe the Developer's Certificate of Origin applies, and it says:
> "using your real name (sorry, no pseudonyms or anonymous
> contributions.)"
I asked him what he prefers - but no response.
> No objection from me, but I think you missed several i2c bus driver
> parameters:
>
> i2c-ali15x3.c:module_param(force_addr, ushort, 0);
> i2c-piix4.c:module_param (force_addr, int, 0);
> i2c-sis5595.c:module_param(force_addr, ushort, 0);
> i2c-viapro.c:module_param(force_addr, ushort, 0);
Okay, thanks. They all seem to encode ioports. All changed.
> And maybe the following ones, but I'm not sure if forcibly enabling a
> device is part of what you need to prevent:
>
> i2c-piix4.c:module_param (force, int, 0);
> i2c-sis630.c:module_param(force, bool, 0);
> i2c-viapro.c:module_param(force, bool, 0);
I don't know either. One could argue it *should* be locked down because its
need appears to reflect a BIOS bug.
David
^ permalink raw reply
* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
From: Jean Delvare @ 2016-12-01 13:47 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
In-Reply-To: <148059544784.31612.17605303556663485588.stgit@warthog.procyon.org.uk>
Hi David,
On jeu., 2016-12-01 at 12:30 +0000, David Howells wrote:
> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image. Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
>
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify. The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
>
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
Initializing the driver when you are not able to honor the user request
looks wrong to me. I don't see how some drivers having sane defaults
justifies that. Using the defaults when no parameters are passed is one
thing (good), still using the defaults when parameters are passed is
another (bad), and you should be able to differentiate between these two
cases.
> This patch annotates drivers in drivers/i2c/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
I know this is only a Suggested-by and not a Signed-off-by, but still I
believe the Developer's Certificate of Origin applies, and it says:
"using your real name (sorry, no pseudonyms or anonymous
contributions.)"
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Wolfram Sang <wsa@the-dreams.de>
> cc: Jean Delvare <jdelvare@suse.com>
> cc: linux-i2c@vger.kernel.org
> ---
>
> drivers/i2c/busses/i2c-elektor.c | 6 +++---
> drivers/i2c/busses/i2c-parport-light.c | 4 ++--
> drivers/i2c/busses/i2c-pca-isa.c | 4 ++--
> drivers/i2c/busses/scx200_acb.c | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
> index 8af62fb3fe41..5416003e0605 100644
> --- a/drivers/i2c/busses/i2c-elektor.c
> +++ b/drivers/i2c/busses/i2c-elektor.c
> @@ -323,9 +323,9 @@ MODULE_AUTHOR("Hans Berglund <hb@spacetec.no>");
> MODULE_DESCRIPTION("I2C-Bus adapter routines for PCF8584 ISA bus adapter");
> MODULE_LICENSE("GPL");
>
> -module_param(base, int, 0);
> -module_param(irq, int, 0);
> +module_param_hw(base, int, ioport_or_iomem, 0);
> +module_param_hw(irq, int, irq, 0);
> module_param(clock, int, 0);
> module_param(own, int, 0);
> -module_param(mmapped, int, 0);
> +module_param_hw(mmapped, int, other, 0);
> module_isa_driver(i2c_elektor_driver, 1);
> diff --git a/drivers/i2c/busses/i2c-parport-light.c b/drivers/i2c/busses/i2c-parport-light.c
> index 1bcdd10b68b9..faa8fb8f2b8f 100644
> --- a/drivers/i2c/busses/i2c-parport-light.c
> +++ b/drivers/i2c/busses/i2c-parport-light.c
> @@ -38,11 +38,11 @@
> static struct platform_device *pdev;
>
> static u16 base;
> -module_param(base, ushort, 0);
> +module_param_hw(base, ushort, ioport, 0);
> MODULE_PARM_DESC(base, "Base I/O address");
>
> static int irq;
> -module_param(irq, int, 0);
> +module_param_hw(irq, int, irq, 0);
> MODULE_PARM_DESC(irq, "IRQ (optional)");
>
> /* ----- Low-level parallel port access ----------------------------------- */
> diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
> index ba88f17f636c..946ac646de2a 100644
> --- a/drivers/i2c/busses/i2c-pca-isa.c
> +++ b/drivers/i2c/busses/i2c-pca-isa.c
> @@ -197,9 +197,9 @@ MODULE_AUTHOR("Ian Campbell <icampbell@arcom.com>");
> MODULE_DESCRIPTION("ISA base PCA9564/PCA9665 driver");
> MODULE_LICENSE("GPL");
>
> -module_param(base, ulong, 0);
> +module_param_hw(base, ulong, ioport, 0);
> MODULE_PARM_DESC(base, "I/O base address");
> -module_param(irq, int, 0);
> +module_param_hw(irq, int, irq, 0);
> MODULE_PARM_DESC(irq, "IRQ");
> module_param(clock, int, 0);
> MODULE_PARM_DESC(clock, "Clock rate in hertz.\n\t\t"
> diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
> index 0a7e410b6195..e0923bee8d1f 100644
> --- a/drivers/i2c/busses/scx200_acb.c
> +++ b/drivers/i2c/busses/scx200_acb.c
> @@ -42,7 +42,7 @@ MODULE_LICENSE("GPL");
>
> #define MAX_DEVICES 4
> static int base[MAX_DEVICES] = { 0x820, 0x840 };
> -module_param_array(base, int, NULL, 0);
> +module_param_hw_array(base, int, ioport, NULL, 0);
> MODULE_PARM_DESC(base, "Base addresses for the ACCESS.bus controllers");
>
> #define POLL_TIMEOUT (HZ/5)
>
>
No objection from me, but I think you missed several i2c bus driver
parameters:
i2c-ali15x3.c:module_param(force_addr, ushort, 0);
i2c-piix4.c:module_param (force_addr, int, 0);
i2c-sis5595.c:module_param(force_addr, ushort, 0);
i2c-viapro.c:module_param(force_addr, ushort, 0);
And maybe the following ones, but I'm not sure if forcibly enabling a
device is part of what you need to prevent:
i2c-piix4.c:module_param (force, int, 0);
i2c-sis630.c:module_param(force, bool, 0);
i2c-viapro.c:module_param(force, bool, 0);
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH] i2c: core: don't try to OF populate DDC i2c buses
From: Vladimir Zapolskiy @ 2016-12-01 12:23 UTC (permalink / raw)
To: Lucas Stach; +Cc: Wolfram Sang, linux-i2c, kernel, patchwork-lst
In-Reply-To: <1480586832.17003.28.camel@pengutronix.de>
On 12/01/2016 12:07 PM, Lucas Stach wrote:
> Am Mittwoch, den 30.11.2016, 22:18 +0200 schrieb Vladimir Zapolskiy:
>> On 11/30/2016 04:06 PM, Lucas Stach wrote:
>>> Am Mittwoch, den 30.11.2016, 15:54 +0200 schrieb Vladimir Zapolskiy:
>>>> Hello Lucas,
>>>>
>>>> On 11/30/2016 01:50 PM, Lucas Stach wrote:
>>>>> DDC buses are manually managed by their consumers to communicate
>>>>> with the display. There is no need to try to populate OF childs.
>>>>>
>>>>> This gets rid of the device create failed warning caused by the
>>>>> core trying to populate a DDC bus below a OF device, which has
>>>>> other childs nodes, that aren't i2c devices.
>>>>
>>>> what kind of devices on a DDC bus represended by children nodes
>>>> do you reference here?
>>>
>>> None. The device registering the DDC i2c adapter might have an of_node.
>>> The children of this device are not i2c devices, but for example port
>>> nodes for the of_graph binding.
>>
>> Port node shall not be a child of any DDC bus device node, otherwise it
>> contradicts to the hierarchy of hardware blocks. It is a common practice
>> to describe port nodes and DDC bus adapter as siblings (devices which
>> share the same display controller / encoder device). Do I miss something?
>>
>>> The same issue can be worked around if we make it explicit by placing an
>>> "i2c-bus" subnode with no children into the parent device OF node. But
>>> as the OF probing of devices on a DDC bus just doesn't make sense I
>>> figured it would be good to just skip all this.
>>>
>>
>> Right, as a micro optimization the change makes sense (*), but the second
>> paragraph in the commit message is questionable.
>>
>> In my opinion it makes sense to include the change, and the warning
>> you mention in the commit message needs its own attention as an indicator
>> of potentially wrongly chosen representation of the device hierarchy.
>>
> Okay to get away from the purely theoretical speaking here: the issue
> this patch fixes is seen with the tc358767 parallel-to-eDP bridge.
> (Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt)
>
> The bridge itself is represented in the DT, so it has a OF node. It then
> goes on to register the i2c over DP AUX channel i2c adapter with its own
> device node, which is what all consumers of the i2c_add_adapter() API so
> AFAICS.
> The i2c adapter has no own representation in the DT, as it's a pure
> software construct, after all it's just an emulated i2c bus over DP,
> there are no physical i2c wires.
>
> The i2c adapter then tries to populate the bridges children as if they
> were i2c devices, which is clearly wrong. We could fix this by creating
> an own device for the i2c adapter, but that's not how things are handled
> today and would require changes to all consumers of this API.
>
Is it correct to register dpaux device node as an I2C bus controller device
node, what is the purpose? If it is has to be done, then bindings/i2c/i2c.txt
documentation must be updated to remove #address-cells and #size-cells
properties from the list of required properties for DDC class adapters.
Shallow review of DTS files and dpaux drivers let me say that the change
below has no regressions (the change is untested):
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82..f91ade1 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1020,7 +1020,6 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
aux->ddc.class = I2C_CLASS_DDC;
aux->ddc.owner = THIS_MODULE;
aux->ddc.dev.parent = aux->dev;
- aux->ddc.dev.of_node = aux->dev->of_node;
strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
sizeof(aux->ddc.name));
--
With best wishes,
Vladimir
^ permalink raw reply related
* [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Jean Delvare, minyard, Wolfram Sang, dhowells,
linux-security-module, keyrings, linux-i2c
In-Reply-To: <148059537897.31612.9461043954611464597.stgit@warthog.procyon.org.uk>
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/i2c/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wolfram Sang <wsa@the-dreams.de>
cc: Jean Delvare <jdelvare@suse.com>
cc: linux-i2c@vger.kernel.org
---
drivers/i2c/busses/i2c-elektor.c | 6 +++---
drivers/i2c/busses/i2c-parport-light.c | 4 ++--
drivers/i2c/busses/i2c-pca-isa.c | 4 ++--
drivers/i2c/busses/scx200_acb.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
index 8af62fb3fe41..5416003e0605 100644
--- a/drivers/i2c/busses/i2c-elektor.c
+++ b/drivers/i2c/busses/i2c-elektor.c
@@ -323,9 +323,9 @@ MODULE_AUTHOR("Hans Berglund <hb@spacetec.no>");
MODULE_DESCRIPTION("I2C-Bus adapter routines for PCF8584 ISA bus adapter");
MODULE_LICENSE("GPL");
-module_param(base, int, 0);
-module_param(irq, int, 0);
+module_param_hw(base, int, ioport_or_iomem, 0);
+module_param_hw(irq, int, irq, 0);
module_param(clock, int, 0);
module_param(own, int, 0);
-module_param(mmapped, int, 0);
+module_param_hw(mmapped, int, other, 0);
module_isa_driver(i2c_elektor_driver, 1);
diff --git a/drivers/i2c/busses/i2c-parport-light.c b/drivers/i2c/busses/i2c-parport-light.c
index 1bcdd10b68b9..faa8fb8f2b8f 100644
--- a/drivers/i2c/busses/i2c-parport-light.c
+++ b/drivers/i2c/busses/i2c-parport-light.c
@@ -38,11 +38,11 @@
static struct platform_device *pdev;
static u16 base;
-module_param(base, ushort, 0);
+module_param_hw(base, ushort, ioport, 0);
MODULE_PARM_DESC(base, "Base I/O address");
static int irq;
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
MODULE_PARM_DESC(irq, "IRQ (optional)");
/* ----- Low-level parallel port access ----------------------------------- */
diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
index ba88f17f636c..946ac646de2a 100644
--- a/drivers/i2c/busses/i2c-pca-isa.c
+++ b/drivers/i2c/busses/i2c-pca-isa.c
@@ -197,9 +197,9 @@ MODULE_AUTHOR("Ian Campbell <icampbell@arcom.com>");
MODULE_DESCRIPTION("ISA base PCA9564/PCA9665 driver");
MODULE_LICENSE("GPL");
-module_param(base, ulong, 0);
+module_param_hw(base, ulong, ioport, 0);
MODULE_PARM_DESC(base, "I/O base address");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
MODULE_PARM_DESC(irq, "IRQ");
module_param(clock, int, 0);
MODULE_PARM_DESC(clock, "Clock rate in hertz.\n\t\t"
diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
index 0a7e410b6195..e0923bee8d1f 100644
--- a/drivers/i2c/busses/scx200_acb.c
+++ b/drivers/i2c/busses/scx200_acb.c
@@ -42,7 +42,7 @@ MODULE_LICENSE("GPL");
#define MAX_DEVICES 4
static int base[MAX_DEVICES] = { 0x820, 0x840 };
-module_param_array(base, int, NULL, 0);
+module_param_hw_array(base, int, ioport, NULL, 0);
MODULE_PARM_DESC(base, "Base addresses for the ACCESS.bus controllers");
#define POLL_TIMEOUT (HZ/5)
^ permalink raw reply related
* [PATCH v7 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v6:
- Revert back A3700_REGS, as asked by Wolfram and define fm_mask
and hs_mask in the register layout. I moved the generic code
for fm_mask and hs_mask to a seperated commit (1/4)
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index b4ac235..6cf333e 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -57,8 +57,12 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
+
/*
* I2C registers definitions
*/
@@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ .fm = ICR_BUSMODE_FM,
+ .hs = ICR_BUSMODE_HS,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox