[PATCH v4] dt-bindings: nvmem: Add syscon to Vybrid OCOTP driver
From: Chris Healy
Add syscon compatibility with Vybrid OCOTP driver binding. This is
required to access the UID.
Fixes: 623069946952 ("nvmem: Add DT binding documentation for Vybrid
OCOTP driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Healy
---
Changes in v4:
- Point to the appropriate commit for the Fixes: line
- Update the Required Properties to add the "syscon" compatible
---
Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
index 56ed481c3e26..72ba628f6d0b 100644
--- a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
@@ -2,7 +2,7 @@ On-Chip OTP Memory for Freescale Vybrid
Required Properties:
compatible:
- - "fsl,vf610-ocotp" for VF5xx/VF6xx
+ - "fsl,vf610-ocotp", "syscon" for VF5xx/VF6xx
#address-cells : Should be 1
#size-cells : Should be 1
reg : Address and length of OTP controller and fuse map registers
@@ -11,7 +11,7 @@ Required Properties:
Example for Vybrid VF5xx/VF6xx:
ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp";
+ compatible = "fsl,vf610-ocotp", "syscon";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x400a5000 0xCF0>;
--
2.26.2
[PATCH v2] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
From: Chris Healy
Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
The end result is that network receive behaviour is marginal with lots of
RX CRC errors experienced and NFS frequently failing.
Quoting the explanation from Andrew Lunn in commit 0672d22a19244
("ARM: dts: imx: Fix the AR803X phy-mode"):
"The problem here is, all the DTs were broken since day 0. However,
because the PHY driver was also broken, nobody noticed and it
worked. Now that the PHY driver has been fixed, all the bugs in the
DTs now become an issue"
Fix it by switching to phy-mode = "rgmii-id".
Fixes: bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031
PHY")
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/imx7d-zii-rmu2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
index e5e20b07f184..7cb6153fc650 100644
--- a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
+++ b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
@@ -58,7 +58,7 @@ {
< IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <_phy>;
status = "okay";
--
2.26.2
Re: [PATCH] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
On Sat, Aug 22, 2020 at 12:59 PM Fabio Estevam wrote:
>
> Hi Chris,
>
> On Mon, Aug 17, 2020 at 12:04 AM Chris Healy wrote:
> >
> > From: Chris Healy
> >
> > Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> > KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
> >
> > Fix it by switching to phy-mode = "rgmii-id".
>
> The patch looks good, but the commit log could be improved to explain
> more about the reason for the breakage.
>
> Please check commit 0672d22a19244 ("ARM: dts: imx: Fix the AR803X
> phy-mode") as a reference.
Sounds good, I'll improve the commit log in v2.
[PATCH v3 2/2] ARM: dts: vfxxx: Add syscon compatible with OCOTP
From: Chris Healy
Add syscon compatibility with Vybrid OCOTP node. This is required to
access the UID.
Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
Cc: sta...@vger.kernel.org
Reviewed-by: Fabio Estevam
Reviewed-by: Stefan Agner
Signed-off-by: Chris Healy
---
Changes in v2:
- Add Fixes line to commit message
Changes in v3:
- Add Reviewed-by tags
---
arch/arm/boot/dts/vfxxx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 0fe03aa0367f..2259d11af721 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -495,7 +495,7 @@ edma1: dma-controller@40098000 {
};
ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp";
+ compatible = "fsl,vf610-ocotp", "syscon";
reg = <0x400a5000 0x1000>;
clocks = < VF610_CLK_OCOTP>;
};
--
2.26.2
[PATCH v3 1/2] dt-bindings: nvmem: Add syscon to Vybrid OCOTP driver
From: Chris Healy
Add syscon compatibility with Vybrid OCOTP driver binding. This is
required to access the UID.
Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Healy
---
Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
index 56ed481c3e26..5db39f399568 100644
--- a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
@@ -11,7 +11,7 @@ Required Properties:
Example for Vybrid VF5xx/VF6xx:
ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp";
+ compatible = "fsl,vf610-ocotp", "syscon";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x400a5000 0xCF0>;
--
2.26.2
Re: [PATCH v2] ARM: dts: vfxxx: Add syscon compatible with ocotp
On Fri, Aug 21, 2020 at 6:21 AM Stefan Agner wrote:
>
> On 2020-08-20 06:10, Chris Healy wrote:
> > From: Chris Healy
> >
> > Add syscon compatibility with Vybrid ocotp node. This is required to
> > access the UID.
>
> Hm, it seems today the SoC driver uses the specific compatible. It also
> should expose the UID as soc_id, see drivers/soc/imx/soc-imx.c.
>
Yes, until I added syscon, the soc_id was empty and I would get the
following line in dmesg: "failed to find vf610-ocotp regmap!
> Maybe it does make sense exposing it as syscon, but then we should
> probably also adjust
> Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt.
>
Makes sense. I will update vf610-ocotp.txt in v3. Tnx
> --
> Stefan
>
> >
> > Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Chris Healy
> > ---
> > Changes in v2:
> > - Add Fixes line to commit message
> >
> > arch/arm/boot/dts/vfxxx.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 0fe03aa0367f..2259d11af721 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -495,7 +495,7 @@ edma1: dma-controller@40098000 {
> > };
> >
> > ocotp: ocotp@400a5000 {
> > - compatible = "fsl,vf610-ocotp";
> > + compatible = "fsl,vf610-ocotp", "syscon";
> > reg = <0x400a5000 0x1000>;
> > clocks = < VF610_CLK_OCOTP>;
> > };
[PATCH v2] ARM: dts: vfxxx: Add syscon compatible with ocotp
From: Chris Healy
Add syscon compatibility with Vybrid ocotp node. This is required to
access the UID.
Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP")
Cc: sta...@vger.kernel.org
Signed-off-by: Chris Healy
---
Changes in v2:
- Add Fixes line to commit message
arch/arm/boot/dts/vfxxx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 0fe03aa0367f..2259d11af721 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -495,7 +495,7 @@ edma1: dma-controller@40098000 {
};
ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp";
+ compatible = "fsl,vf610-ocotp", "syscon";
reg = <0x400a5000 0x1000>;
clocks = < VF610_CLK_OCOTP>;
};
--
2.26.2
Re: [PATCH] ARM: dts: vfxxx: Add syscon compatible with ocotp
On Wed, Aug 19, 2020 at 3:08 PM Fabio Estevam wrote: > > Hi Chris, > > On Sun, Aug 16, 2020 at 11:28 PM Chris Healy wrote: > > > > From: Chris Healy > > > > Add syscon compatibility with Vybrid ocotp node. This is required to > > access the UID. > > > > Signed-off-by: Chris Healy > > Would a Fixes tag be appropriate here so that it can be backported to > older stable kernels? Good point, I will add that in v2.
[PATCH] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
From: Chris Healy
Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
Fix it by switching to phy-mode = "rgmii-id".
Fixes: bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031
PHY")
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/imx7d-zii-rmu2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
index e5e20b07f184..7cb6153fc650 100644
--- a/arch/arm/boot/dts/imx7d-zii-rmu2.dts
+++ b/arch/arm/boot/dts/imx7d-zii-rmu2.dts
@@ -58,7 +58,7 @@ {
< IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <_phy>;
status = "okay";
--
2.26.2
[PATCH] ARM: dts: vfxxx: Add syscon compatible with ocotp
From: Chris Healy
Add syscon compatibility with Vybrid ocotp node. This is required to
access the UID.
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vfxxx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 0fe03aa0367f..2259d11af721 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -495,7 +495,7 @@ edma1: dma-controller@40098000 {
};
ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp";
+ compatible = "fsl,vf610-ocotp", "syscon";
reg = <0x400a5000 0x1000>;
clocks = < VF610_CLK_OCOTP>;
};
--
2.26.2
[PATCH v2] ARM: dts: ZII: Disable HW Ethernet switch reset GPIOs
From: Chris Healy
Disable Ethernet switch reset GPIO with ZII platforms that have it
enabled. HW switch reset results in a reset of the copper PHYs
inside of the switch. We want to avoid this reset of the copper PHYs
in the switch as this results in unnecessary broader network disruption on
a soft reboot of the application processor.
With the HW GPIO removed, the switch driver still performs a soft reset of
the switch core which has been shown to sufficiently meet our needs with
other ZII platforms that do not have the HW switch reset GPIO defined.
Signed-off-by: Chris Healy
---
v2:
- Update the description to more accurately reflect why we are making the change
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 --
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 --
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 --
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 --
4 files changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index 64e0e9509226..50da0c94e1b7 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -172,7 +172,6 @@ switch0: switch0@0 {
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
@@ -356,7 +355,6 @@ VF610_PAD_PTE13__GPIO_118 0x3043
pinctrl_switch: switch-grp {
fsl,pins = <
VF610_PAD_PTB28__GPIO_980x3061
- VF610_PAD_PTE2__GPIO_1070x1042
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 9e5187ba3fa6..6c6ec46fd015 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -129,7 +129,6 @@ switch0: switch0@0 {
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -326,7 +325,6 @@ VF610_PAD_PTC17__ENET_RMII1_TXEN0x30d2
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index 569614b08f04..73fdace4cb42 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -118,7 +118,6 @@ switch0: switch0@0 {
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -293,7 +292,6 @@ VF610_PAD_PTB24__GPIO_940x219d
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index b6b0f302b7b4..fe600ab2e4bd 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -143,7 +143,6 @@ switch0: switch0@0 {
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -333,7 +332,6 @@ VF610_PAD_PTC17__ENET_RMII1_TXEN0x30d2
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
--
2.26.2
Re: [PATCH] ARM: dts: ZII: Disable HW Ethernet switch reset GPIO
On Sun, Jul 19, 2020 at 8:15 PM Shawn Guo wrote:
>
> On Wed, Jul 15, 2020 at 02:22:27PM -0700, Chris Healy wrote:
> > Disable Ethernet switch reset GPIO with ZII platforms that have it
> > enabled to sync up with existing ZII platforms that already have
> > it disabled.
>
> I do not follow it. The reset GPIO is part of hardware description. We
> shouldn't add or remove it for sake of sync-up with other platforms.
I see that my description is not very good. What I should have said
is that we don't want to use the HW reset GPIO as it results in things
being done that we do not want done. Specifically, when the switch is
hit with the HW reset GPIO, it results in the switch's copper PHYs
being HW reset which we want to avoid as this results in unnecessary
network downtime on a soft reboot of the processor. With the HW reset
GPIO not in the devicetree description, the switch driver resorts to
doing a SW reset which resets the switch core but not the switch's
copper PHYs. This results in a much shorter network downtime on a
soft reboot of the processor.
I can do a v2 of the patch with the description updated if you think
it would be appropriate.
>
> Shawn
>
> >
> > Signed-off-by: Chris Healy
> > ---
> > arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 --
> > arch/arm/boot/dts/vf610-zii-spb4.dts | 2 --
> > arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 --
> > arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 --
> > 4 files changed, 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> > b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> > index ce1920c052fc..c2668230a4c0 100644
> > --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> > +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> > @@ -170,7 +170,6 @@
> > interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > interrupt-controller;
> > #interrupt-cells = <2>;
> > - reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> >
> > ports {
> > #address-cells = <1>;
> > @@ -354,7 +353,6 @@
> > pinctrl_switch: switch-grp {
> > fsl,pins = <
> > VF610_PAD_PTB28__GPIO_980x3061
> > - VF610_PAD_PTE2__GPIO_1070x1042
> > >;
> > };
> >
> > diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
> > b/arch/arm/boot/dts/vf610-zii-spb4.dts
> > index 55b4201e27f6..261317340189 100644
> > --- a/arch/arm/boot/dts/vf610-zii-spb4.dts
> > +++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
> > @@ -127,7 +127,6 @@
> > pinctrl-names = "default";
> > reg = <0>;
> > eeprom-length = <65536>;
> > - reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > interrupt-parent = <>;
> > interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > interrupt-controller;
> > @@ -312,7 +311,6 @@
> >
> > pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
> > fsl,pins = <
> > - VF610_PAD_PTE2__GPIO_1070x31c2
> > VF610_PAD_PTB28__GPIO_980x219d
> > >;
> > };
> > diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
> > b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
> > index a6c22a79779e..e37b9643269b 100644
> > --- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
> > +++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
> > @@ -113,7 +113,6 @@
> > pinctrl-names = "default";
> > reg = <0>;
> > eeprom-length = <65536>;
> > - reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> > interrupt-parent = <>;
> > interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > interrupt-controller;
> > @@ -288,7 +287,6 @@
> >
> > pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
> > fsl,pins = <
> > - VF610_PAD_PTE2__GPIO_1070x31c2
> > VF610_PAD_PTB28__GPIO_980x219d
> > >;
> > };
> > diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
> > b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
> > index 3d05c894bdc0..b3d6d4b9fa9c 100644
> > --- a/arch/arm/boot/dts/vf610-zi
[PATCH] ARM: dts: vf610-zii-ssmb-spu3: Add node for switch watchdog
Add I2C child node for switch watchdog present on SPU3
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index b3d6d4b9fa9c..d55ceb5afe1d 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -225,6 +225,18 @@
};
};
+ {
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1>;
+ status = "okay";
+
+ watchdog@38 {
+ compatible = "zii,rave-wdt";
+ reg = <0x38>;
+ };
+};
+
{
status = "disabled";
};
--
2.21.3
[PATCH v2] ARM: dts: vf610-zii-ssmb-dtu: Add no-sdio/no-sd properties
esdhc0 is connected to an eMMC, so it is safe to pass the "no-sdio"/"no-sd" properties. esdhc1 is wired to a standard SD socket, so pass the "no-sdio" property. Signed-off-by: Chris Healy Reviewed-by: Fabio Estevam --- v2: - Fix formatting so patch applies cleanly - Add Fabio's reviewed-by - Update subject line per Shawn's recommendation arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts index e37b9643269b..3ecc1ad5abea 100644 --- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts +++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts @@ -81,6 +81,8 @@ non-removable; no-1-8-v; keep-power-in-suspend; + no-sdio; + no-sd; status = "okay"; }; @@ -88,6 +90,7 @@ pinctrl-names = "default"; pinctrl-0 = <_esdhc1>; bus-width = <4>; + no-sdio; status = "okay"; }; -- 2.21.3
[PATCH] ARM: dts: ZII: Disable HW Ethernet switch reset GPIO
Disable Ethernet switch reset GPIO with ZII platforms that have it
enabled to sync up with existing ZII platforms that already have
it disabled.
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 --
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 --
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 --
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 --
4 files changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..c2668230a4c0 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -170,7 +170,6 @@
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
@@ -354,7 +353,6 @@
pinctrl_switch: switch-grp {
fsl,pins = <
VF610_PAD_PTB28__GPIO_980x3061
- VF610_PAD_PTE2__GPIO_1070x1042
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..261317340189 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -127,7 +127,6 @@
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -312,7 +311,6 @@
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..e37b9643269b 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -113,7 +113,6 @@
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -288,7 +287,6 @@
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..b3d6d4b9fa9c 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -141,7 +141,6 @@
pinctrl-names = "default";
reg = <0>;
eeprom-length = <65536>;
- reset-gpios = < 11 GPIO_ACTIVE_LOW>;
interrupt-parent = <>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
@@ -319,7 +318,6 @@
pinctrl_gpio_switch0: pinctrl-gpio-switch0 {
fsl,pins = <
- VF610_PAD_PTE2__GPIO_1070x31c2
VF610_PAD_PTB28__GPIO_980x219d
>;
};
--
2.21.3
[PATCH net-next] net: phy: sfp: Cotsworks SFF module EEPROM fixup
Some Cotsworks SFF have invalid data in the first few bytes of the
module EEPROM. This results in these modules not being detected as
valid modules.
Address this by poking the correct EEPROM values into the module
EEPROM when the model/PN match and the existing module EEPROM contents
are not correct.
Signed-off-by: Chris Healy
---
drivers/net/phy/sfp.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..2737d9b6b0ae 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1632,10 +1632,43 @@ static int sfp_sm_mod_hpower(struct sfp *sfp, bool
enable)
return 0;
}
+static int sfp_cotsworks_fixup_check(struct sfp *sfp, struct sfp_eeprom_id *id)
+{
+ u8 check;
+ int err;
+
+ if (id->base.phys_id != SFF8024_ID_SFF_8472 ||
+ id->base.phys_ext_id != SFP_PHYS_EXT_ID_SFP ||
+ id->base.connector != SFF8024_CONNECTOR_LC) {
+ dev_warn(sfp->dev, "Rewriting fiber module EEPROM with
corrected values\n");
+ id->base.phys_id = SFF8024_ID_SFF_8472;
+ id->base.phys_ext_id = SFP_PHYS_EXT_ID_SFP;
+ id->base.connector = SFF8024_CONNECTOR_LC;
+ err = sfp_write(sfp, false, SFP_PHYS_ID, >base, 3);
+ if (err != 3) {
+ dev_err(sfp->dev, "Failed to rewrite module EEPROM:
%d\n", err);
+ return err;
+ }
+
+ /* Cotsworks modules have been found to require a delay between
write operations. */
+ mdelay(50);
+
+ /* Update base structure checksum */
+ check = sfp_check(>base, sizeof(id->base) - 1);
+ err = sfp_write(sfp, false, SFP_CC_BASE, , 1);
+ if (err != 1) {
+ dev_err(sfp->dev, "Failed to update base structure
checksum in fiber module EEPROM: %d\n", err);
+ return err;
+ }
+ }
+ return 0;
+}
+
static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
{
/* SFP module inserted - read I2C data */
struct sfp_eeprom_id id;
+ bool cotsworks_sfbg;
bool cotsworks;
u8 check;
int ret;
@@ -1657,6 +1690,17 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
* serial number and date code.
*/
cotsworks = !memcmp(id.base.vendor_name, "COTSWORKS ", 16);
+ cotsworks_sfbg = !memcmp(id.base.vendor_pn, "SFBG", 4);
+
+ /* Cotsworks SFF module EEPROM do not always have valid phys_id,
+* phys_ext_id, and connector bytes. Rewrite SFF EEPROM bytes if
+* Cotsworks PN matches and bytes are not correct.
+*/
+ if (cotsworks && cotsworks_sfbg) {
+ ret = sfp_cotsworks_fixup_check(sfp, );
+ if (ret < 0)
+ return ret;
+ }
/* Validate the checksum over the base structure */
check = sfp_check(, sizeof(id.base) - 1);
--
2.21.3
[PATCH] ARM: dts: vf610-zii-spb4: Add node for switch watchdog
Add I2C child node for switch watchdog present on SPB4
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vf610-zii-spb4.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index a68eae88174a..9e5187ba3fa6 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -209,6 +209,18 @@
};
};
+ {
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1>;
+ status = "okay";
+
+ watchdog@38 {
+ compatible = "zii,rave-wdt";
+ reg = <0x38>;
+ };
+};
+
{
status = "disabled";
};
@@ -326,6 +338,13 @@
>;
};
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ VF610_PAD_PTB16__I2C1_SCL 0x37ff
+ VF610_PAD_PTB17__I2C1_SDA 0x37ff
+ >;
+ };
+
pinctrl_leds_debug: pinctrl-leds-debug {
fsl,pins = <
VF610_PAD_PTD3__GPIO_82 0x31c2
--
2.21.3
[PATCH v4] ARM: dts: vfxxx: Add node for CAAM
From: Andrey Smirnov
Add node for CAAM device in NXP Vybrid SoC.
Signed-off-by: Andrey Smirnov
Signed-off-by: Chris Healy
Reviewed-by: Fabio Estevam
---
v4:
- really add reviewed by from Fabio Estevam
v3:
- put version information in the correct place
- add reviewed by from Fabio Estevam
v2:
- fixup commit to show that this patch is from Andrey Smirnov
arch/arm/boot/dts/vfxxx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
dma-names = "rx","tx";
status = "disabled";
};
+
+ crypto: crypto@400f {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400f 0x9000>;
+ ranges = <0 0x400f 0x9000>;
+ clocks = < VF610_CLK_CAAM>;
+ clock-names = "ipg";
+
+ sec_jr0: jr0@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr1@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
};
};
};
--
2.21.3
[PATCH v3] ARM: dts: vfxxx: Add node for CAAM
From: Andrey Smirnov
Add node for CAAM device in NXP Vybrid SoC.
Signed-off-by: Andrey Smirnov
Signed-off-by: Chris Healy
---
v3:
- put version information in the correct place
- add reviewed by from Fabio Estevam
v2:
- fixup commit to show that this patch is from Andrey Smirnov
arch/arm/boot/dts/vfxxx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
dma-names = "rx","tx";
status = "disabled";
};
+
+ crypto: crypto@400f {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400f 0x9000>;
+ ranges = <0 0x400f 0x9000>;
+ clocks = < VF610_CLK_CAAM>;
+ clock-names = "ipg";
+
+ sec_jr0: jr0@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr1@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
};
};
};
--
2.21.3
[PATCH net-next] net: dsa: mv88e6xxx: Add serdes read/write dynamic debug
Add deb_dbg print statements in both serdes_read and serdes_write
functions.
Signed-off-by: Chris Healy
---
drivers/net/dsa/mv88e6xxx/serdes.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c
b/drivers/net/dsa/mv88e6xxx/serdes.c
index 9c07b4f3d345..756b34343547 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -20,14 +20,25 @@
static int mv88e6352_serdes_read(struct mv88e6xxx_chip *chip, int reg,
u16 *val)
{
- return mv88e6xxx_phy_page_read(chip, MV88E6352_ADDR_SERDES,
+ int err;
+
+ err = mv88e6xxx_phy_page_read(chip, MV88E6352_ADDR_SERDES,
MV88E6352_SERDES_PAGE_FIBER,
reg, val);
+
+ if (err)
+ return err;
+
+ dev_dbg(chip->dev, "serdes <- reg: 0x%.2x val: 0x%.2x\n", reg, *val);
+
+ return 0;
}
static int mv88e6352_serdes_write(struct mv88e6xxx_chip *chip, int reg,
u16 val)
{
+ dev_dbg(chip->dev, "serdes -> reg: 0x%.2x val: 0x%.2x\n", reg, val);
+
return mv88e6xxx_phy_page_write(chip, MV88E6352_ADDR_SERDES,
MV88E6352_SERDES_PAGE_FIBER,
reg, val);
@@ -37,8 +48,17 @@ static int mv88e6390_serdes_read(struct mv88e6xxx_chip *chip,
int lane, int device, int reg, u16 *val)
{
int reg_c45 = MII_ADDR_C45 | device << 16 | reg;
+ int err;
+
+ err = mv88e6xxx_phy_read(chip, lane, reg_c45, val);
+ if (err)
+ return err;
+
+ dev_dbg(chip->dev, "serdes <- lane: %.2d device: 0x%.2x reg_c45: 0x%.4x
val: 0x%.4x\n",
+ lane, device, reg_c45, *val);
+
+ return 0;
- return mv88e6xxx_phy_read(chip, lane, reg_c45, val);
}
static int mv88e6390_serdes_write(struct mv88e6xxx_chip *chip,
@@ -46,6 +66,9 @@ static int mv88e6390_serdes_write(struct mv88e6xxx_chip *chip,
{
int reg_c45 = MII_ADDR_C45 | device << 16 | reg;
+ dev_dbg(chip->dev, "serdes -> lane: %.2d device: 0x%.2x reg_c45: 0x%.4x
val: 0x%.4x\n",
+ lane, device, reg_c45, val);
+
return mv88e6xxx_phy_write(chip, lane, reg_c45, val);
}
--
2.21.3
[PATCH v2] arm: dts: vf610-zii-scu4-aib: Configure fibre ports to 1000BaseX
From: Andrew Lunn
The SFF soldered onto the board expect the ports to use 1000BaseX. It
makes no sense to have the ports set to SGMII, since they don't even
support that mode.
Signed-off-by: Andrew Lunn
Signed-off-by: Chris Healy
---
v2:
- convert spaces back to tabs
- Correct from line to show Andrew as the original author
arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
index b642520199ba..040a1f8b6130 100644
--- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
+++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
@@ -186,7 +186,7 @@
port@2 {
reg = <2>;
label = "eth_fc_1000_2";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -194,7 +194,7 @@
port@3 {
reg = <3>;
label = "eth_fc_1000_3";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -202,7 +202,7 @@
port@4 {
reg = <4>;
label = "eth_fc_1000_4";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -210,7 +210,7 @@
port@5 {
reg = <5>;
label = "eth_fc_1000_5";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -218,7 +218,7 @@
port@6 {
reg = <6>;
label = "eth_fc_1000_6";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -226,7 +226,7 @@
port@7 {
reg = <7>;
label = "eth_fc_1000_7";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -234,7 +234,7 @@
port@9 {
reg = <9>;
label = "eth_fc_1000_1";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -269,7 +269,7 @@
port@2 {
reg = <2>;
label = "eth_fc_1000_8";
- phy-mode = &quo
[PATCH v2] ARM: dts: vf610-zii-dev-rev-c: Configure fiber port to 1000BaseX
The SFF soldered onto the board expects the port to use 1000BaseX. It
makes no sense to have the port set to SGMII, since it doesn't even
support that mode.
Signed-off-by: Chris Healy
---
v2:
- convert spaces back to tabs
- remove .dts from subject line
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index 778e02c000d1..de79dcfd32e6 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -164,7 +164,7 @@
port@9 {
reg = <9>;
label = "sff2";
- phy-mode = "sgmii";
+ phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
--
2.21.3
Re: [PATCH] ARM: dts: vf610-zii-dev-rev-c.dts: Configure fibre port to 1000BaseX
On Wed, Jul 8, 2020 at 11:41 AM Fabio Estevam wrote:
>
> Hi Chris,
>
> In the Subject you could remove the .dts from the dts name:
>
> ARM: dts: vf610-zii-dev-rev-c: Configure fibre port to 1000BaseX
>
> On Sun, Jul 5, 2020 at 9:51 PM Chris Healy wrote:
> >
> > The SFF soldered onto the board expects the port to use 1000BaseX. It
> > makes no sense to have the port set to SGMII, since it doesn't even
> > support that mode.
> >
> > Signed-off-by: Chris Healy
> > ---
> > arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
> > b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
> > index 778e02c000d1..de79dcfd32e6 100644
> > --- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
> > +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
> > @@ -164,7 +164,7 @@
> > port@9 {
> > reg = <9>;
> > label = "sff2";
> > -phy-mode = "sgmii";
> > +phy-mode = "1000base-x";
>
> Looks like tabs were converted to spaces.
I'll make both changes and submit a v2, thanks.
[PATCH v3] arm: dts: ZII: update MDIO speed and preamble
Update MDIO configuration with ZII devices to fully utilize
MDIO endpoint capabilities. All devices support 12.5MHz clock and
don't require MDIO preable.
Signed-off-by: Chris Healy
Reviewed-by: Fabio Estevam
---
v3:
- make "status = okay" the last property
v2:
- Fix subject line to reference ZII:
- Get rid of "=<1>;" from suppress-preamble lines
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 ++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 20350e803377..5af9ce977b12 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -719,6 +719,8 @@
mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch: switch@0 {
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..64e0e9509226 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -158,6 +158,8 @@
mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch0: switch0@0 {
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi
b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 95d0060fb56c..f8299f33a692 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -137,6 +137,8 @@
mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..a68eae88174a 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -119,6 +119,8 @@
mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch0: switch0@0 {
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..fa5ac9125af7 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -105,6 +105,8 @@
mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch0: switch0@0 {
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..801133154e3d 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -133,6 +133,8 @@
mdio1: mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch0: switch0@0 {
--
2.21.3
[PATCH v3] arm64: dts: zii-ultra: update MDIO speed and preamble
Update MDIO configuration with zii-ultra device to fully utilize
MDIO endpoint capabilities. Device supports 12.5MHz clock and
doesn't require MDIO preamble.
Signed-off-by: Chris Healy
---
v3:
- make "status = okay" the last property
v2:
- Fix subject line to reference zii-ultra:
- Get rid of "=<1>;" from suppress-preamble lines
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 6a55165bd76a..0d1088dcaa02 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -131,6 +131,8 @@
mdio {
#address-cells = <1>;
#size-cells = <0>;
+ clock-frequency = <1250>;
+ suppress-preamble;
status = "okay";
switch: switch@0 {
--
2.21.3
Re: [PATCH v2] arm64: dts: zii-ultra: update MDIO speed and preamble device
On Tue, Jul 7, 2020 at 5:41 PM Fabio Estevam wrote: > > Hi Chris, > > On Tue, Jul 7, 2020 at 9:32 PM Chris Healy wrote: > > > #address-cells = <1>; > > #size-cells = <0>; > > status = "okay"; > > + suppress-preamble; > > + clock-frequency = <1250>; > > Sorry, I missed this in the previous review. > > The recommendation is to have status = okay as the last property. > > Please move suppress-preamble and clock-frequency = <1250> prior > to status = "okay" Will do in the next version.
[PATCH v2] arm64: dts: zii-ultra: update MDIO speed and preamble device
Update MDIO configuration with zii-ultra device to fully utilize
MDIO endpoint capabilities. Device supports 12.5MHz clock and
doesn't require MDIO preamble.
Signed-off-by: Chris Healy
---
v2:
- Fix subject line to reference zii-ultra:
- Get rid of "=<1>;" from suppress-preamble lines
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 6a55165bd76a..98aa67a4c040 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -132,6 +132,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
--
2.21.3
[PATCH v2] ARM: dts: ZII: update MDIO speed and preamble
Update MDIO configuration with ZII devices to fully utilize
MDIO endpoint capabilities. All devices support 12.5MHz clock and
don't require MDIO preable.
Signed-off-by: Chris Healy
Reviewed-by: Fabio Estevam
---
v2:
- Fix subject line to reference ZII:
- Get rid of "=<1>;" from suppress-preamble lines
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 ++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 20350e803377..58cc421042e1 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -720,6 +720,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..c27cacbe6a73 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -159,6 +159,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi
b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 95d0060fb56c..9694d3b53607 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -138,6 +138,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
};
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..d2ad07ed5318 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -120,6 +120,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..0bb3dcff0b79 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -106,6 +106,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..e12e11805b71 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -134,6 +134,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+ suppress-preamble;
+ clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
--
2.21.3
Re: [PATCH] ARM64: dts: update MDIO speed and preamble for zii-ultra device
On Tue, Jul 7, 2020 at 2:54 PM Fabio Estevam wrote: > > Hi Chris, > > The subject pattern used for ARM64 i.MX patches is like: > > arm64: dts: zii-ultra: update MDIO speed and preamble Thanks for pointing this out. I have to make a change to this patch anyway so I will resubmit with the correct subject pattern. > > On Sat, Jul 4, 2020 at 10:26 PM Chris Healy wrote: > > > > Update MDIO configuration with zii-ultra device to fully utilize > > MDIO endpoint capabilities. Device supports 12.5MHz clock and > > doesn't require MDIO preamble. > > > > Signed-off-by: Chris Healy > > Other than that: > > Reviewed-by: Fabio Estevam
Re: [PATCH] ARM64: dts: update MDIO speed and preamble for zii-ultra device
On Tue, Jul 7, 2020 at 2:59 PM Florian Fainelli wrote: > > Hi Chris, > > On 7/4/2020 6:26 PM, Chris Healy wrote: > > Update MDIO configuration with zii-ultra device to fully utilize > > MDIO endpoint capabilities. Device supports 12.5MHz clock and > > doesn't require MDIO preamble. > > > > Signed-off-by: Chris Healy > > --- > > arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi > > b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi > > index 6a55165bd76a..98aa67a4c040 100644 > > --- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi > > +++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi > > @@ -132,6 +132,8 @@ > > #address-cells = <1>; > > #size-cells = <0>; > > status = "okay"; > > +suppress-preamble = <1>; > > suppress-preamble is defined as a boolean, so you can remove the "= <1>" > part entirely. Good point, I'll make the necessary change. > -- > Florian
[PATCH v2] ARM: dts: vfxxx: Add node for CAAM
From: Andrey Smirnov
Add node for CAAM device in NXP Vybrid SoC.
Signed-off-by: Andrey Smirnov
Signed-off-by: Chris Healy
v2:
- fixup commit to show that this patch is from Andrey Smirnov.
---
arch/arm/boot/dts/vfxxx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
dma-names = "rx","tx";
status = "disabled";
};
+
+ crypto: crypto@400f {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400f 0x9000>;
+ ranges = <0 0x400f 0x9000>;
+ clocks = < VF610_CLK_CAAM>;
+ clock-names = "ipg";
+
+ sec_jr0: jr0@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr1@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
};
};
};
--
2.21.3
[PATCH net-next] net: sfp: add error checking with sfp_irq_name
Add error checking with sfp_irq_name before use. Signed-off-by: Chris Healy --- drivers/net/phy/sfp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c index 7bdfcde98266..eef458ab0e5b 100644 --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -2354,6 +2354,9 @@ static int sfp_probe(struct platform_device *pdev) "%s-%s", dev_name(sfp->dev), gpio_of_names[i]); + if (!sfp_irq_name) + return -ENOMEM; + err = devm_request_threaded_irq(sfp->dev, sfp->gpio_irq[i], NULL, sfp_irq, IRQF_ONESHOT | -- 2.21.3
Re: [PATCH net-next v3] net: sfp: Unique GPIO interrupt names
On Mon, Jul 6, 2020 at 11:52 PM Andy Shevchenko
wrote:
>
>
>
> On Tuesday, July 7, 2020, Chris Healy wrote:
>>
>> From: Chris Healy
>>
>> Dynamically generate a unique GPIO interrupt name, based on the
>> device name and the GPIO name. For example:
>>
>> 103: 0 sx1503q 12 Edge sff2-los
>> 104: 0 sx1503q 13 Edge sff2-tx-fault
>>
>> The sffX indicates the SFP the los and tx-fault are associated with.
>>
>> Signed-off-by: Chris Healy
>>
>> v3:
>> - reverse Christmas tree new variable
>> - fix spaces vs tabs
>> v2:
>> - added net-next to PATCH part of subject line
>> - switched to devm_kasprintf()
>> ---
>> drivers/net/phy/sfp.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
>> index 73c2969f11a4..7bdfcde98266 100644
>> --- a/drivers/net/phy/sfp.c
>> +++ b/drivers/net/phy/sfp.c
>> @@ -2238,6 +2238,7 @@ static int sfp_probe(struct platform_device *pdev)
>> {
>> const struct sff_data *sff;
>> struct i2c_adapter *i2c;
>> + char *sfp_irq_name;
>> struct sfp *sfp;
>> int err, i;
>>
>> @@ -2349,12 +2350,16 @@ static int sfp_probe(struct platform_device *pdev)
>> continue;
>> }
>>
>> + sfp_irq_name = devm_kasprintf(sfp->dev, GFP_KERNEL,
>> + "%s-%s", dev_name(sfp->dev),
>> + gpio_of_names[i]);
>
>
>
> No error check? Why?
Good point. I will add this. I see this patch was just applied so
I'll submit a follow on patch to add the appropriate error check.
>
>
>>
>> +
>> err = devm_request_threaded_irq(sfp->dev, sfp->gpio_irq[i],
>> NULL, sfp_irq,
>> IRQF_ONESHOT |
>> IRQF_TRIGGER_RISING |
>> IRQF_TRIGGER_FALLING,
>> - dev_name(sfp->dev), sfp);
>> + sfp_irq_name, sfp);
>> if (err) {
>> sfp->gpio_irq[i] = 0;
>> sfp->need_poll = true;
>> --
>> 2.21.3
>>
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
[PATCH net-next v3] net: sfp: Unique GPIO interrupt names
From: Chris Healy
Dynamically generate a unique GPIO interrupt name, based on the
device name and the GPIO name. For example:
103: 0 sx1503q 12 Edge sff2-los
104: 0 sx1503q 13 Edge sff2-tx-fault
The sffX indicates the SFP the los and tx-fault are associated with.
Signed-off-by: Chris Healy
v3:
- reverse Christmas tree new variable
- fix spaces vs tabs
v2:
- added net-next to PATCH part of subject line
- switched to devm_kasprintf()
---
drivers/net/phy/sfp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..7bdfcde98266 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2238,6 +2238,7 @@ static int sfp_probe(struct platform_device *pdev)
{
const struct sff_data *sff;
struct i2c_adapter *i2c;
+ char *sfp_irq_name;
struct sfp *sfp;
int err, i;
@@ -2349,12 +2350,16 @@ static int sfp_probe(struct platform_device *pdev)
continue;
}
+ sfp_irq_name = devm_kasprintf(sfp->dev, GFP_KERNEL,
+ "%s-%s", dev_name(sfp->dev),
+ gpio_of_names[i]);
+
err = devm_request_threaded_irq(sfp->dev, sfp->gpio_irq[i],
NULL, sfp_irq,
IRQF_ONESHOT |
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
- dev_name(sfp->dev), sfp);
+ sfp_irq_name, sfp);
if (err) {
sfp->gpio_irq[i] = 0;
sfp->need_poll = true;
--
2.21.3
[PATCH net-next v2] net: sfp: Unique GPIO interrupt names
Dynamically generate a unique GPIO interrupt name, based on the
device name and the GPIO name. For example:
103: 0 sx1503q 12 Edge sff2-los
104: 0 sx1503q 13 Edge sff2-tx-fault
The sffX indicates the SFP the los and tx-fault are associated with.
Signed-off-by: Chris Healy
v2:
- added net-next to PATCH part of subject line
- switched to devm_kasprintf()
---
drivers/net/phy/sfp.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..193a124c26c4 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2239,6 +2239,7 @@ static int sfp_probe(struct platform_device *pdev)
const struct sff_data *sff;
struct i2c_adapter *i2c;
struct sfp *sfp;
+char *sfp_irq_name;
int err, i;
sfp = sfp_alloc(>dev);
@@ -2349,12 +2350,16 @@ static int sfp_probe(struct platform_device *pdev)
continue;
}
+sfp_irq_name = devm_kasprintf(sfp->dev, GFP_KERNEL,
+ "%s-%s", dev_name(sfp->dev),
+ gpio_of_names[i]);
+
err = devm_request_threaded_irq(sfp->dev, sfp->gpio_irq[i],
NULL, sfp_irq,
IRQF_ONESHOT |
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
-dev_name(sfp->dev), sfp);
+sfp_irq_name, sfp);
if (err) {
sfp->gpio_irq[i] = 0;
sfp->need_poll = true;
--
2.21.3
Re: [PATCH] net: sfp: Unique GPIO interrupt names
On Mon, Jul 6, 2020 at 1:42 PM Russell King - ARM Linux admin
wrote:
>
> On Mon, Jul 06, 2020 at 12:38:37PM -0700, Chris Healy wrote:
> > Dynamically generate a unique GPIO interrupt name, based on the
> > device name and the GPIO name. For example:
> >
> > 103: 0 sx1503q 12 Edge sff2-los
> > 104: 0 sx1503q 13 Edge sff3-los
> >
> > The sffX indicates the SFP the loss of signal GPIO is associated with.
> >
> > Signed-off-by: Chris Healy
>
> This doesn't work in all cases.
>
> > ---
> > drivers/net/phy/sfp.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > index 73c2969f11a4..9b03c7229320 100644
> > --- a/drivers/net/phy/sfp.c
> > +++ b/drivers/net/phy/sfp.c
> > @@ -220,6 +220,7 @@ struct sfp {
> > struct phy_device *mod_phy;
> > const struct sff_data *type;
> > u32 max_power_mW;
> > +char sfp_irq_name[32];
> >
> > unsigned int (*get_state)(struct sfp *);
> > void (*set_state)(struct sfp *, unsigned int);
> > @@ -2349,12 +2350,15 @@ static int sfp_probe(struct platform_device *pdev)
> > continue;
> > }
> >
> > +snprintf(sfp->sfp_irq_name, sizeof(sfp->sfp_irq_name),
> > + "%s-%s", dev_name(sfp->dev), gpio_of_names[i]);
>
> sfp_irq_name will be overwritten for each GPIO IRQ claimed, which means
> all IRQs for a particular cage will end up with the same name.
> sfp_irq_name[] therefore needs to be an array of names, one per input.
Good point. I'll add the necessary support to deal with this case and
test on my side with a hacked up devicetree file providing some
additional GPIOs and include this in the next version of the patch.
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH] net: sfp: Unique GPIO interrupt names
On Mon, Jul 6, 2020 at 1:07 PM Andrew Lunn wrote:
>
> On Mon, Jul 06, 2020 at 12:38:37PM -0700, Chris Healy wrote:
> > Dynamically generate a unique GPIO interrupt name, based on the
> > device name and the GPIO name. For example:
> >
> > 103: 0 sx1503q 12 Edge sff2-los
> > 104: 0 sx1503q 13 Edge sff3-los
> >
> > The sffX indicates the SFP the loss of signal GPIO is associated with.
>
> Hi Chris
>
> For netdev, please put inside the [PATCH] part of the subject, which
> tree this is for, i.e. net-next.
Will do.
>
> > Signed-off-by: Chris Healy
> > ---
> > drivers/net/phy/sfp.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > index 73c2969f11a4..9b03c7229320 100644
> > --- a/drivers/net/phy/sfp.c
> > +++ b/drivers/net/phy/sfp.c
> > @@ -220,6 +220,7 @@ struct sfp {
> > struct phy_device *mod_phy;
> > const struct sff_data *type;
> > u32 max_power_mW;
> > +char sfp_irq_name[32];
> >
> > unsigned int (*get_state)(struct sfp *);
> > void (*set_state)(struct sfp *, unsigned int);
> > @@ -2349,12 +2350,15 @@ static int sfp_probe(struct platform_device *pdev)
> > continue;
> > }
> >
> > +snprintf(sfp->sfp_irq_name, sizeof(sfp->sfp_irq_name),
> > + "%s-%s", dev_name(sfp->dev), gpio_of_names[i]);
> > +
>
> This is perfectly O.K, but you could consider using
> devm_kasprintf(). That will allocate as much memory as needed for the
> string, and hence avoid truncation issues, which we have seen before
> with other interrupt names.
I'll give this a try for the next version of this patch.
>
> Andrew
[PATCH] net: sfp: Unique GPIO interrupt names
Dynamically generate a unique GPIO interrupt name, based on the
device name and the GPIO name. For example:
103: 0 sx1503q 12 Edge sff2-los
104: 0 sx1503q 13 Edge sff3-los
The sffX indicates the SFP the loss of signal GPIO is associated with.
Signed-off-by: Chris Healy
---
drivers/net/phy/sfp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 73c2969f11a4..9b03c7229320 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -220,6 +220,7 @@ struct sfp {
struct phy_device *mod_phy;
const struct sff_data *type;
u32 max_power_mW;
+char sfp_irq_name[32];
unsigned int (*get_state)(struct sfp *);
void (*set_state)(struct sfp *, unsigned int);
@@ -2349,12 +2350,15 @@ static int sfp_probe(struct platform_device *pdev)
continue;
}
+snprintf(sfp->sfp_irq_name, sizeof(sfp->sfp_irq_name),
+ "%s-%s", dev_name(sfp->dev), gpio_of_names[i]);
+
err = devm_request_threaded_irq(sfp->dev, sfp->gpio_irq[i],
NULL, sfp_irq,
IRQF_ONESHOT |
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
-dev_name(sfp->dev), sfp);
+sfp->sfp_irq_name, sfp);
if (err) {
sfp->gpio_irq[i] = 0;
sfp->need_poll = true;
--
2.21.3
[PATCH] arm: DT: vf610-zii-scu4-aib.dts: Configure fibre ports to 1000BaseX
The SFF soldered onto the board expect the ports to use 1000BaseX. It
makes no sense to have the ports set to SGMII, since they don't even
support that mode.
Signed-off-by: Andrew Lunn
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
index b642520199ba..040a1f8b6130 100644
--- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
+++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
@@ -186,7 +186,7 @@
port@2 {
reg = <2>;
label = "eth_fc_1000_2";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -194,7 +194,7 @@
port@3 {
reg = <3>;
label = "eth_fc_1000_3";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -202,7 +202,7 @@
port@4 {
reg = <4>;
label = "eth_fc_1000_4";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -210,7 +210,7 @@
port@5 {
reg = <5>;
label = "eth_fc_1000_5";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -218,7 +218,7 @@
port@6 {
reg = <6>;
label = "eth_fc_1000_6";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -226,7 +226,7 @@
port@7 {
reg = <7>;
label = "eth_fc_1000_7";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -234,7 +234,7 @@
port@9 {
reg = <9>;
label = "eth_fc_1000_1";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -269,7 +269,7 @@
port@2 {
reg = <2>;
label = "eth_fc_1000_8";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -277,7 +277,7 @@
port@3 {
reg = <3>;
label = "eth_fc_1000_9";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
@@ -285,7 +285,7 @@
port@4 {
reg = <4>;
label = "eth_fc_1000_10";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
--
2.21.3
[PATCH] ARM: dts: vf610-zii-dev-rev-c.dts: Configure fibre port to 1000BaseX
The SFF soldered onto the board expects the port to use 1000BaseX. It
makes no sense to have the port set to SGMII, since it doesn't even
support that mode.
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index 778e02c000d1..de79dcfd32e6 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -164,7 +164,7 @@
port@9 {
reg = <9>;
label = "sff2";
-phy-mode = "sgmii";
+phy-mode = "1000base-x";
managed = "in-band-status";
sfp = <>;
};
--
2.21.3
[PATCH] ARM: dts: vf610-zii-ssmb-dtu: Pass "no-sdio"/"no-sd" properties
esdhc0 is connected to an eMMC, so it is safe to pass the "no-sdio"/"no-sd" properties. esdhc1 is wired to a standard SD socket, so pass the "no-sdio" property. Signed-off-by: Chris Healy --- arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts index 0bb3dcff0b79..7d4ddfb6b5b5 100644 --- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts +++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts @@ -81,6 +81,8 @@ non-removable; no-1-8-v; keep-power-in-suspend; +no-sdio; +no-sd; status = "okay"; }; @@ -88,6 +90,7 @@ pinctrl-names = "default"; pinctrl-0 = <_esdhc1>; bus-width = <4>; +no-sdio; status = "okay"; }; -- 2.21.3
[PATCH] ARM: dts: vfxxx: Add node for CAAM
Add node for CAAM device in NXP Vybrid SoC.
Signed-off-by: Andrey Smirnov
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vfxxx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
dma-names = "rx","tx";
status = "disabled";
};
+
+crypto: crypto@400f {
+compatible = "fsl,sec-v4.0";
+#address-cells = <1>;
+#size-cells = <1>;
+reg = <0x400f 0x9000>;
+ranges = <0 0x400f 0x9000>;
+clocks = < VF610_CLK_CAAM>;
+clock-names = "ipg";
+
+sec_jr0: jr0@1000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x1000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+sec_jr1: jr1@2000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x2000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+};
};
};
};
--
2.21.3
[PATCH] ARM64: dts: update MDIO speed and preamble for zii-ultra device
Update MDIO configuration with zii-ultra device to fully utilize
MDIO endpoint capabilities. Device supports 12.5MHz clock and
doesn't require MDIO preamble.
Signed-off-by: Chris Healy
---
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 6a55165bd76a..98aa67a4c040 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -132,6 +132,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
--
2.21.3
[PATCH] ARM: dts: update MDIO speed and preamble for zii devices
Update MDIO configuration with zii devices to fully utilize
MDIO endpoint capabilities. All devices support 12.5MHz clock and
don't require MDIO preamble.
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 ++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 20350e803377..58cc421042e1 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -720,6 +720,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..c27cacbe6a73 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -159,6 +159,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi
b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 95d0060fb56c..9694d3b53607 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -138,6 +138,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
};
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..d2ad07ed5318 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -120,6 +120,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..0bb3dcff0b79 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -106,6 +106,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..e12e11805b71 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -134,6 +134,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
--
2.21.3
Re: [PATCH] clk: imx: vf610: add CAAM clock
On a Vybrid VF610 based platform I tested this with 5.8-rc1. With the
necessary DTS patch, the CAAM worked correctly for me.
Tested-by: Chris Healy
On Mon, Jun 1, 2020 at 4:06 PM Andrey Smirnov wrote:
>
> According to Vybrid Security RM, CCM_CCGR11[CG176] can be used to gate
> CAAM ipg clock.
>
> Signed-off-by: Horia Geantă
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Shawn Guo
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@nxp.com
> ---
> drivers/clk/imx/clk-vf610.c | 1 +
> include/dt-bindings/clock/vf610-clock.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> index cd04e7dc1878..5129ef8e1d6e 100644
> --- a/drivers/clk/imx/clk-vf610.c
> +++ b/drivers/clk/imx/clk-vf610.c
> @@ -438,6 +438,7 @@ static void __init vf610_clocks_init(struct device_node
> *ccm_node)
> clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6,
> CCM_CCGRx_CGn(7));
> clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR,
> 24);
> clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6,
> CCM_CCGRx_CGn(5));
> + clk[VF610_CLK_CAAM] = imx_clk_gate2("caam", "ipg_bus", CCM_CCGR11,
> CCM_CCGRx_CGn(0));
>
> imx_check_clocks(clk, ARRAY_SIZE(clk));
>
> diff --git a/include/dt-bindings/clock/vf610-clock.h
> b/include/dt-bindings/clock/vf610-clock.h
> index 95394f35a74a..0f2d60e884dc 100644
> --- a/include/dt-bindings/clock/vf610-clock.h
> +++ b/include/dt-bindings/clock/vf610-clock.h
> @@ -195,6 +195,7 @@
> #define VF610_CLK_WKPU 186
> #define VF610_CLK_TCON0187
> #define VF610_CLK_TCON1188
> -#define VF610_CLK_END 189
> +#define VF610_CLK_CAAM 189
> +#define VF610_CLK_END 190
>
> #endif /* __DT_BINDINGS_CLOCK_VF610_H */
> --
> 2.21.3
Re: [PATCH] crypto: caam - make soc match data optional
With all four of Vybrid VF610, i.MX6q, i.MX6qp, and i.MX8M, this patch
caused no regressions for me. Additionally, with the VF610 and a
follow on devicetree patch, the CAAM is detected and works.
Tested by: Chris Healy
On Fri, May 15, 2020 at 9:23 PM Andrey Smirnov wrote:
>
> Vyrbrid devices don't have any clock that need to be taken care of, so
> make clock data optional on i.MX.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Fabio Estevam
> Cc: linux-...@nxp.com
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/crypto/caam/ctrl.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 4fcdd262e581..6aba430793cc 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -630,12 +630,7 @@ static int caam_probe(struct platform_device *pdev)
> imx_soc_match = soc_device_match(caam_imx_soc_table);
> caam_imx = (bool)imx_soc_match;
>
> - if (imx_soc_match) {
> - if (!imx_soc_match->data) {
> - dev_err(dev, "No clock data provided for i.MX SoC");
> - return -EINVAL;
> - }
> -
> + if (imx_soc_match && imx_soc_match->data) {
> ret = init_clocks(dev, imx_soc_match->data);
> if (ret)
> return ret;
> --
> 2.21.3
Re: [PATCH] ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect'
On Thu, Oct 3, 2019 at 10:41 PM Andrey Smirnov wrote:
>
> Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
> board, since both are connected to the same parent bus and all of
> their children have the same I2C address.
>
> Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board")
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Cory Tusar
> Cc: Jeff White
> Cc: Rick Ramstetter
> Cc: Lucas Stach
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Shawn:
>
> If this is possible, I'd like this one to go into 5.4.
>
> Thanks,
> Andrey Smirnov
>
> arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> index dc8a5f37a1ef..c8ebb23c4e02 100644
> --- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> +++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> @@ -602,6 +602,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x70>;
> + i2c-mux-idle-disconnect;
>
> sff0_i2c: i2c@1 {
> #address-cells = <1>;
> @@ -640,6 +641,7 @@
> reg = <0x71>;
> #address-cells = <1>;
> #size-cells = <0>;
> + i2c-mux-idle-disconnect;
>
> sff5_i2c: i2c@1 {
> #address-cells = <1>;
> --
> 2.21.0
>
On an SCU4 AIB, this series is:
Tested-by: Chris Healy
Re: [PATCH v2 00/21] Refine memblock API
> > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > hardware requires command buffers within the first 2GiB of physical > RAM. > I thought that the i.MX6q has the MMUv1 and GC2000 GPU while the i.MX6qp has the MMUv2 and GC3000? Meaning the i.MX6 has both MMUv1 and MMUv2 depending on which i.MX6 part we are talking about.
Re: [PATCH] ARM: dts: vf610-zii-scu4-aib: Configure IRQ line for GPIO expander
On Fri, Aug 23, 2019 at 5:27 PM Andrey Smirnov wrote:
>
> Configure IRQ line for SX1503 GPIO expander. We already have
> appropriate pinmux entry and all that is missing is "interrupt-parent"
> and "interrupts" properties. Add them.
>
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Cory Tusar
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> index e6c3621079e0..45a978defbdc 100644
> --- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> +++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
> @@ -570,6 +570,8 @@
> #gpio-cells = <2>;
> reg = <0x20>;
> gpio-controller;
> + interrupt-parent = <>;
> + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
> };
>
> lm75@4e {
> --
Tested-by: Chris Healy
Re: [PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
On Mon, Aug 19, 2019 at 8:08 PM Andrey Smirnov wrote:
>
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
>
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> index ff460a1de85a..28732249cfc0 100644
> --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> @@ -207,7 +207,7 @@
> };
>
> {
> - clock-frequency = <40>;
> + clock-frequency = <10>;
> pinctrl-names = "default";
> pinctrl-0 = <_i2c0>;
> status = "okay";
> --
> 2.21.0
>
Reviewed-by: Chris Healy
Re: [PATCH] ARM: vf610-zii-cfu1: Add node for switch watchdog
Tested-by: Chris Healy
On Wed, Aug 14, 2019 at 12:35 PM Andrey Smirnov
wrote:
>
> Add I2C child node for switch watchdog present on CFU1.
>
> Signed-off-by: Andrey Smirnov
> Signed-off-by: Cory Tusar
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Fabio Estevam
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-cfu1.dts | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> index 7267873b5369..18c19c092dd1 100644
> --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> @@ -239,6 +239,18 @@
> };
> };
>
> + {
> + clock-frequency = <10>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c1>;
> + status = "okay";
> +
> + watchdog@38 {
> + compatible = "zii,rave-wdt";
> + reg = <0x38>;
> + };
> +};
> +
> {
> status = "disabled";
> };
> @@ -324,6 +336,13 @@
> >;
> };
>
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + VF610_PAD_PTB16__I2C1_SCL 0x37ff
> + VF610_PAD_PTB17__I2C1_SDA 0x37ff
> + >;
> + };
> +
> pinctrl_leds_debug: pinctrl-leds-debug {
> fsl,pins = <
> VF610_PAD_PTD3__GPIO_82 0x31c2
> --
> 2.21.0
>
Re: [PATCH v3 0/2] HWMON compatibility layer for power supplies
> This small series contains the code I wrote to expose various power > supply sensors via HWMON layer in order to be able to access all of > the sensors in the system with libsensors. > > Changes since [v2]: Full series is tested using the UCS1002. Tested-by: cphe...@gmail.com
Re: [PATCH 2/3] ARM: dts: imx6: rdu2: Disable WP for USDHC2 and USDHC3
> RDU2 production units come with resistor connecting WP pin to > correpsonding GPIO DNPed for both SD card slots. Drop any WP related > configuration and mark both slots with "disable-wp". > > Reported-by: Chris Healy > Signed-off-by: Andrey Smirnov > Cc: Shawn Guo > Cc: Fabio Estevam > Cc: Lucas Stach > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi > b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi > index 977d923e35df..5484e4b87975 100644 > --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi > +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi > @@ -625,7 +625,7 @@ > pinctrl-0 = <_usdhc2>; Reviewed-by: Chris Healy
Re: [PATCH 3/3] ARM: dts: imx6: rdu2: Limit USBH1 to Full Speed
> > Am Mittwoch, den 22.05.2019, 00:12 -0700 schrieb Andrey Smirnov: > > > Cabling used to connect devices to USBH1 on RDU2 does not meet USB > > > spec cable quality and cable length requirements to operate at High > > > Speed, so limit the port to Full Speed only. > > > > Really? I thought this issue is specific to the RDU1, but you've been > > looking at this USB stuff for a lot longer than me. > > > > I am merely a messenger here. I didn't personally verify this to be > the case, so your knowledge is probably as good as mine. Chris > reported this based on feedback from their EE team, so he should know > all of the details better. The issue is less about the internals of the device and more about the cabling that the device is connected to. In the target application of this device, the USB cables are almost always longer than the spec limit of the USB standard for high speed. Given our use cases, we don't have need for high speed so limiting the max speed to full speed is the way we work around cables that are too long for stable high speed operation. We have validated that running with full speed does mitigate the problems experienced when attempting to run with high speed on the target application installations. Reviewed-by: Chris Healy
Re: [PATCH] mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values
Tested on a i.MX51 platform with rev 2.4 PMIC silicon. System reboots
without the patch. System works correctly with the patch in place and
reports a sane temperature.
Tested-by: Chris Healy
On Tue, Aug 28, 2018 at 1:02 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> When trying to read any MC13892 ADC channel on a imx51-babbage board:
>
> # cat /sys/class/hwmon/hwmon0/device/in7_input
>
> The MC13892 PMIC shutdowns completely.
>
> After debugging this issue and comparing the MC13892 and MC13783
> initializations done in the vendor kernel, it was noticed that the
> CHRGRAWDIV bit of the ADC0 register was not being set.
>
> This bit is set by default after power on, but the driver was
> clearing it.
>
> After setting this bit it is possible to read the ADC values correctly.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/mfd/mc13xxx-core.c | 3 ++-
> include/linux/mfd/mc13xxx.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index c63e331..f475e84 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -276,7 +276,8 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx,
> unsigned int mode,
>
> mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, _adc0);
>
> - adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2;
> + adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
> + MC13XXX_ADC0_CHRGRAWDIV;
> adc1 = MC13XXX_ADC1_ADEN | MC13XXX_ADC1_ADTRIGIGN | MC13XXX_ADC1_ASC;
>
> /*
> diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
> index 54a3cd8..2ad9bdc 100644
> --- a/include/linux/mfd/mc13xxx.h
> +++ b/include/linux/mfd/mc13xxx.h
> @@ -249,6 +249,7 @@ struct mc13xxx_platform_data {
> #define MC13XXX_ADC0_TSMOD0(1 << 12)
> #define MC13XXX_ADC0_TSMOD1(1 << 13)
> #define MC13XXX_ADC0_TSMOD2(1 << 14)
> +#define MC13XXX_ADC0_CHRGRAWDIV(1 << 15)
> #define MC13XXX_ADC0_ADINC1(1 << 16)
> #define MC13XXX_ADC0_ADINC2(1 << 17)
>
> --
> 2.7.4
>
Re: [PATCH] mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values
Tested on a i.MX51 platform with rev 2.4 PMIC silicon. System reboots
without the patch. System works correctly with the patch in place and
reports a sane temperature.
Tested-by: Chris Healy
On Tue, Aug 28, 2018 at 1:02 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> When trying to read any MC13892 ADC channel on a imx51-babbage board:
>
> # cat /sys/class/hwmon/hwmon0/device/in7_input
>
> The MC13892 PMIC shutdowns completely.
>
> After debugging this issue and comparing the MC13892 and MC13783
> initializations done in the vendor kernel, it was noticed that the
> CHRGRAWDIV bit of the ADC0 register was not being set.
>
> This bit is set by default after power on, but the driver was
> clearing it.
>
> After setting this bit it is possible to read the ADC values correctly.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/mfd/mc13xxx-core.c | 3 ++-
> include/linux/mfd/mc13xxx.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index c63e331..f475e84 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -276,7 +276,8 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx,
> unsigned int mode,
>
> mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, _adc0);
>
> - adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2;
> + adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
> + MC13XXX_ADC0_CHRGRAWDIV;
> adc1 = MC13XXX_ADC1_ADEN | MC13XXX_ADC1_ADTRIGIGN | MC13XXX_ADC1_ASC;
>
> /*
> diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
> index 54a3cd8..2ad9bdc 100644
> --- a/include/linux/mfd/mc13xxx.h
> +++ b/include/linux/mfd/mc13xxx.h
> @@ -249,6 +249,7 @@ struct mc13xxx_platform_data {
> #define MC13XXX_ADC0_TSMOD0(1 << 12)
> #define MC13XXX_ADC0_TSMOD1(1 << 13)
> #define MC13XXX_ADC0_TSMOD2(1 << 14)
> +#define MC13XXX_ADC0_CHRGRAWDIV(1 << 15)
> #define MC13XXX_ADC0_ADINC1(1 << 16)
> #define MC13XXX_ADC0_ADINC2(1 << 17)
>
> --
> 2.7.4
>
Re: [PATCH] ARM: dts: vf610: Add ZII CFU1 board
> Add support for the Zodiac Inflight Innovations CFU1 > board (VF610-based). > > Cc: Shawn Guo > Cc: Fabio Estevam > Cc: cphe...@gmail.com > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrew Lunn > Signed-off-by: Andrey Smirnov > --- > > Shawn: > > Currently this patch is rebase on top of [spu3], if that is > problematic, let me know and I'll update it accordingly > > Thanks, > Andrey Smirnov > > [spu3] lkml.kernel.org/r/20180717040651.641-1-andrew.smir...@gmail.com > > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/vf610-zii-cfu1.dts | 307 +++ > 2 files changed, 308 insertions(+) > create mode 100644 arch/arm/boot/dts/vf610-zii-cfu1.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index e331b2c16539..85797819fdd9 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -569,6 +569,7 @@ dtb-$(CONFIG_SOC_VF610) += \ > vf610-cosmic.dtb \ > vf610m4-cosmic.dtb \ > vf610-twr.dtb \ > + vf610-zii-cfu1.dtb \ > vf610-zii-dev-rev-b.dtb \ Tested-by: Chris Healy
Re: [PATCH] ARM: dts: vf610: Add ZII CFU1 board
> Add support for the Zodiac Inflight Innovations CFU1 > board (VF610-based). > > Cc: Shawn Guo > Cc: Fabio Estevam > Cc: cphe...@gmail.com > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrew Lunn > Signed-off-by: Andrey Smirnov > --- > > Shawn: > > Currently this patch is rebase on top of [spu3], if that is > problematic, let me know and I'll update it accordingly > > Thanks, > Andrey Smirnov > > [spu3] lkml.kernel.org/r/20180717040651.641-1-andrew.smir...@gmail.com > > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/vf610-zii-cfu1.dts | 307 +++ > 2 files changed, 308 insertions(+) > create mode 100644 arch/arm/boot/dts/vf610-zii-cfu1.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index e331b2c16539..85797819fdd9 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -569,6 +569,7 @@ dtb-$(CONFIG_SOC_VF610) += \ > vf610-cosmic.dtb \ > vf610m4-cosmic.dtb \ > vf610-twr.dtb \ > + vf610-zii-cfu1.dtb \ > vf610-zii-dev-rev-b.dtb \ Tested-by: Chris Healy
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Tue, Jul 17, 2018 at 8:20 AM, Andrew Lunn wrote: >> >> +++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> >> @@ -0,0 +1,343 @@ >> >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> >> + >> >> +/* >> >> + * Device tree file for ZII's SSMB SPU3 board >> >> + * >> >> + * SSMB - SPU3 Switch Management Board >> >> + * SPU - Seat Power Unit >> > >> > I think this is the first Zodiac board with mutually recursive >> > acronyms. >> > >> > Probably a question for Chris: Does SSMB specifically refer to version >> > 3 of the SPU? >> > >> >Andrew >> >> SPU3 is the third generation of seat power unit. >> SSMB is the SPU3 Switch Management Board. >> >> So, SSMB is a backronym. This naming scheme breaks down a bit though >> when follow on designs (that are not the SPU3) also use the SSMB, but >> that's what it is... ;-) > > O.K, i was just wondering if the 3 was in the wrong place. More > logically, it would be > > * SSMB - SPU Switch Management Board > * SPU 3 - Seat Power Unit, version 3. > > But you are saying the Marketing guys messed up the naming and > engineering is now stuck with it. > Yep
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Tue, Jul 17, 2018 at 8:20 AM, Andrew Lunn wrote: >> >> +++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> >> @@ -0,0 +1,343 @@ >> >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> >> + >> >> +/* >> >> + * Device tree file for ZII's SSMB SPU3 board >> >> + * >> >> + * SSMB - SPU3 Switch Management Board >> >> + * SPU - Seat Power Unit >> > >> > I think this is the first Zodiac board with mutually recursive >> > acronyms. >> > >> > Probably a question for Chris: Does SSMB specifically refer to version >> > 3 of the SPU? >> > >> >Andrew >> >> SPU3 is the third generation of seat power unit. >> SSMB is the SPU3 Switch Management Board. >> >> So, SSMB is a backronym. This naming scheme breaks down a bit though >> when follow on designs (that are not the SPU3) also use the SSMB, but >> that's what it is... ;-) > > O.K, i was just wondering if the 3 was in the wrong place. More > logically, it would be > > * SSMB - SPU Switch Management Board > * SPU 3 - Seat Power Unit, version 3. > > But you are saying the Marketing guys messed up the naming and > engineering is now stuck with it. > Yep
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Mon, Jul 16, 2018 at 9:06 PM, Andrey Smirnov wrote: > Add support for Zodiac Inflight Innovations SSMB SPU3 > board (VF610-based). > > Cc: Shawn Guo > Cc: Fabio Estevam > Cc: cphe...@gmail.com > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrew Lunn > Signed-off-by: Andrey Smirnov > --- > arch/arm/boot/dts/Makefile| 3 +- > arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 343 ++ > 2 files changed, 345 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index bea41b129493..e331b2c16539 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -570,7 +570,8 @@ dtb-$(CONFIG_SOC_VF610) += \ > vf610m4-cosmic.dtb \ > vf610-twr.dtb \ > vf610-zii-dev-rev-b.dtb \ > - vf610-zii-dev-rev-c.dtb > + vf610-zii-dev-rev-c.dtb \ > + vf610-zii-ssmb-spu3.dtb Tested-by: Chris Healy
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Mon, Jul 16, 2018 at 9:06 PM, Andrey Smirnov wrote: > Add support for Zodiac Inflight Innovations SSMB SPU3 > board (VF610-based). > > Cc: Shawn Guo > Cc: Fabio Estevam > Cc: cphe...@gmail.com > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrew Lunn > Signed-off-by: Andrey Smirnov > --- > arch/arm/boot/dts/Makefile| 3 +- > arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 343 ++ > 2 files changed, 345 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index bea41b129493..e331b2c16539 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -570,7 +570,8 @@ dtb-$(CONFIG_SOC_VF610) += \ > vf610m4-cosmic.dtb \ > vf610-twr.dtb \ > vf610-zii-dev-rev-b.dtb \ > - vf610-zii-dev-rev-c.dtb > + vf610-zii-dev-rev-c.dtb \ > + vf610-zii-ssmb-spu3.dtb Tested-by: Chris Healy
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Tue, Jul 17, 2018 at 7:46 AM, Andrew Lunn wrote: > On Mon, Jul 16, 2018 at 09:06:51PM -0700, Andrey Smirnov wrote: >> Add support for Zodiac Inflight Innovations SSMB SPU3 >> board (VF610-based). >> >> Cc: Shawn Guo >> Cc: Fabio Estevam >> Cc: cphe...@gmail.com >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: devicet...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Andrew Lunn >> Signed-off-by: Andrey Smirnov >> --- >> arch/arm/boot/dts/Makefile| 3 +- >> arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 343 ++ >> 2 files changed, 345 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index bea41b129493..e331b2c16539 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -570,7 +570,8 @@ dtb-$(CONFIG_SOC_VF610) += \ >> vf610m4-cosmic.dtb \ >> vf610-twr.dtb \ >> vf610-zii-dev-rev-b.dtb \ >> - vf610-zii-dev-rev-c.dtb >> + vf610-zii-dev-rev-c.dtb \ >> + vf610-zii-ssmb-spu3.dtb >> dtb-$(CONFIG_ARCH_MXS) += \ >> imx23-evk.dtb \ >> imx23-olinuxino.dtb \ >> diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> new file mode 100644 >> index ..b692117d7839 >> --- /dev/null >> +++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> @@ -0,0 +1,343 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> + >> +/* >> + * Device tree file for ZII's SSMB SPU3 board >> + * >> + * SSMB - SPU3 Switch Management Board >> + * SPU - Seat Power Unit > > I think this is the first Zodiac board with mutually recursive > acronyms. > > Probably a question for Chris: Does SSMB specifically refer to version > 3 of the SPU? > >Andrew SPU3 is the third generation of seat power unit. SSMB is the SPU3 Switch Management Board. So, SSMB is a backronym. This naming scheme breaks down a bit though when follow on designs (that are not the SPU3) also use the SSMB, but that's what it is... ;-)
Re: [PATCH] ARM: dts: vf610: Add ZII SSMB SPU3 board
On Tue, Jul 17, 2018 at 7:46 AM, Andrew Lunn wrote: > On Mon, Jul 16, 2018 at 09:06:51PM -0700, Andrey Smirnov wrote: >> Add support for Zodiac Inflight Innovations SSMB SPU3 >> board (VF610-based). >> >> Cc: Shawn Guo >> Cc: Fabio Estevam >> Cc: cphe...@gmail.com >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: devicet...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Andrew Lunn >> Signed-off-by: Andrey Smirnov >> --- >> arch/arm/boot/dts/Makefile| 3 +- >> arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 343 ++ >> 2 files changed, 345 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index bea41b129493..e331b2c16539 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -570,7 +570,8 @@ dtb-$(CONFIG_SOC_VF610) += \ >> vf610m4-cosmic.dtb \ >> vf610-twr.dtb \ >> vf610-zii-dev-rev-b.dtb \ >> - vf610-zii-dev-rev-c.dtb >> + vf610-zii-dev-rev-c.dtb \ >> + vf610-zii-ssmb-spu3.dtb >> dtb-$(CONFIG_ARCH_MXS) += \ >> imx23-evk.dtb \ >> imx23-olinuxino.dtb \ >> diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> new file mode 100644 >> index ..b692117d7839 >> --- /dev/null >> +++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts >> @@ -0,0 +1,343 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> + >> +/* >> + * Device tree file for ZII's SSMB SPU3 board >> + * >> + * SSMB - SPU3 Switch Management Board >> + * SPU - Seat Power Unit > > I think this is the first Zodiac board with mutually recursive > acronyms. > > Probably a question for Chris: Does SSMB specifically refer to version > 3 of the SPU? > >Andrew SPU3 is the third generation of seat power unit. SSMB is the SPU3 Switch Management Board. So, SSMB is a backronym. This naming scheme breaks down a bit though when follow on designs (that are not the SPU3) also use the SSMB, but that's what it is... ;-)
Re: [PATCH 2/2] ARM: dts: imx51-zii-scu3-esb: Fix RAVE SP watchdog compatible string
Tested-by: Chris Healy
watchdog driver loads and works now.
On Wed, Jul 11, 2018 at 7:33 PM, Andrey Smirnov
wrote:
> It looks like I made a nasty typo in the original patch which resulted
> in missing watchdog device. Fix it.
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Andrew Lunn
> Signed-off-by: Andrey Smirnov
> ---
> arch/arm/boot/dts/imx51-zii-scu3-esb.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> b/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> index 0bb42c00d72b..dffb761a1cc8 100644
> --- a/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> +++ b/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> @@ -325,7 +325,7 @@
> #size-cells = <1>;
>
> watchdog {
> - compatible = "zii,rave-sp-watchodg-legacy";
> + compatible = "zii,rave-sp-watchdog-legacy";
> };
>
> eeprom@a4 {
> --
> 2.17.1
>
Re: [PATCH 2/2] ARM: dts: imx51-zii-scu3-esb: Fix RAVE SP watchdog compatible string
Tested-by: Chris Healy
watchdog driver loads and works now.
On Wed, Jul 11, 2018 at 7:33 PM, Andrey Smirnov
wrote:
> It looks like I made a nasty typo in the original patch which resulted
> in missing watchdog device. Fix it.
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Andrew Lunn
> Signed-off-by: Andrey Smirnov
> ---
> arch/arm/boot/dts/imx51-zii-scu3-esb.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> b/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> index 0bb42c00d72b..dffb761a1cc8 100644
> --- a/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> +++ b/arch/arm/boot/dts/imx51-zii-scu3-esb.dts
> @@ -325,7 +325,7 @@
> #size-cells = <1>;
>
> watchdog {
> - compatible = "zii,rave-sp-watchodg-legacy";
> + compatible = "zii,rave-sp-watchdog-legacy";
> };
>
> eeprom@a4 {
> --
> 2.17.1
>
Re: [PATCH] ARM: dts: imx: Add ZII SCU2 Mezz board
Successfully tested on an SCU2 Mezz board.
Tested-by: Chris Healy
On Fri, Jul 6, 2018 at 7:49 PM, Andrey Smirnov wrote:
> Add support for the Zodiac Inflight Innovations SCU2 Mezz
> board (i.MX51-based).
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Fabio Estevam
> Signed-off-by: Andrey Gusakov
> Signed-off-by: Andrey Smirnov
> ---
>
> Shawn:
>
> This is a spin-off of SCU2 Mezz board support originally found in [v0]
> as per out off-list (Fabio, Chris, Nikita, myself) to add support for
> ZII hardware fist and worry about factoring out commonalites later.
>
> Original submission was done by Andrey Gusakov, but he is too busy on
> other projects, so the honors of submitting this were delegated to me.
>
> NOTE: RAVE SP ("zii,rave-sp-mezz") node is technically supported by
> upstream, but it needs some fixes from [rave-sp-fixes] to work
> correctly. If you want me to drop that node until [rave-sp-fixes] is
> merged, let me know.
>
> Changes since [v0]:
>
> - Patch converted to be a standalone file not dependent on any
>ZII-specific .dtsi
>
> - Added RAVE SP node with all the children that are currently
>supported by upstream
>
> - Droppped ecspi2 node. That node didn't have any child devices in
>[v0] because none of the chips connected to that bus are supported
>upstream. This node can be added later once anything attached to it
>has upstream drivers.
>
> - Dropped i2c_gpio. That bus was originally added for RAVE SP related
>prototyping and is unused in actual product.
>
> - Various newline fixes pointed out in [v0]
>
> - Most of then nodes should be sorted alphabetically (I might have
>missed some)
>
> - Collected Reviewed-by from Fabio (Fabio, I assumed you won't mind,
>but let me know if you want me to drop it)
>
> [v0]
> lkml.kernel.org/r/1529603100-31958-4-git-send-email-andrey.gusa...@cogentembedded.com
> [rave-sp-fixes]
> lkml.kernel.org/r/20180707024108.32373-1-andrew.smir...@gmail.com
>
> arch/arm/boot/dts/Makefile| 3 +-
> arch/arm/boot/dts/imx51-zii-scu2-mezz.dts | 448 ++
> 2 files changed, 450 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx51-zii-scu2-mezz.dts
Re: [PATCH] ARM: dts: imx: Add ZII SCU2 Mezz board
Successfully tested on an SCU2 Mezz board.
Tested-by: Chris Healy
On Fri, Jul 6, 2018 at 7:49 PM, Andrey Smirnov wrote:
> Add support for the Zodiac Inflight Innovations SCU2 Mezz
> board (i.MX51-based).
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Fabio Estevam
> Signed-off-by: Andrey Gusakov
> Signed-off-by: Andrey Smirnov
> ---
>
> Shawn:
>
> This is a spin-off of SCU2 Mezz board support originally found in [v0]
> as per out off-list (Fabio, Chris, Nikita, myself) to add support for
> ZII hardware fist and worry about factoring out commonalites later.
>
> Original submission was done by Andrey Gusakov, but he is too busy on
> other projects, so the honors of submitting this were delegated to me.
>
> NOTE: RAVE SP ("zii,rave-sp-mezz") node is technically supported by
> upstream, but it needs some fixes from [rave-sp-fixes] to work
> correctly. If you want me to drop that node until [rave-sp-fixes] is
> merged, let me know.
>
> Changes since [v0]:
>
> - Patch converted to be a standalone file not dependent on any
>ZII-specific .dtsi
>
> - Added RAVE SP node with all the children that are currently
>supported by upstream
>
> - Droppped ecspi2 node. That node didn't have any child devices in
>[v0] because none of the chips connected to that bus are supported
>upstream. This node can be added later once anything attached to it
>has upstream drivers.
>
> - Dropped i2c_gpio. That bus was originally added for RAVE SP related
>prototyping and is unused in actual product.
>
> - Various newline fixes pointed out in [v0]
>
> - Most of then nodes should be sorted alphabetically (I might have
>missed some)
>
> - Collected Reviewed-by from Fabio (Fabio, I assumed you won't mind,
>but let me know if you want me to drop it)
>
> [v0]
> lkml.kernel.org/r/1529603100-31958-4-git-send-email-andrey.gusa...@cogentembedded.com
> [rave-sp-fixes]
> lkml.kernel.org/r/20180707024108.32373-1-andrew.smir...@gmail.com
>
> arch/arm/boot/dts/Makefile| 3 +-
> arch/arm/boot/dts/imx51-zii-scu2-mezz.dts | 448 ++
> 2 files changed, 450 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx51-zii-scu2-mezz.dts
Re: [PATCH v4] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
On Wed, Jun 20, 2018 at 1:35 PM, Nick Dyer wrote:
> The pinctrl settings were incorrect for the touchscreen interrupt line,
> causing
> an interrupt storm. This change has been tested with both the atmel_mxt_ts and
> RMI4 drivers on the RDU1 units.
>
> The value 0x4 comes from the value of register IOMUXC_SW_PAD_CTL_PAD_CSI1_D8
> from the old vendor kernel.
>
> Signed-off-by: Nick Dyer
> Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
> Cc: # 4.15+
> Reviewed-by: Fabio Estevam
> ---
> Changes in v4:
> - Add reviewed by Fabio
> Changes in v3:
> - Update commit message to add source of 0x4 value, fixes tag and CC stable
> Changes in v2:
> - Use hex, only alter IRQ line config
Tested on an RDU1 with Synaptics touchscreen successfully. No
interrupt store any longer...
Tested-by: Chris Healy
Re: [PATCH v4] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
On Wed, Jun 20, 2018 at 1:35 PM, Nick Dyer wrote:
> The pinctrl settings were incorrect for the touchscreen interrupt line,
> causing
> an interrupt storm. This change has been tested with both the atmel_mxt_ts and
> RMI4 drivers on the RDU1 units.
>
> The value 0x4 comes from the value of register IOMUXC_SW_PAD_CTL_PAD_CSI1_D8
> from the old vendor kernel.
>
> Signed-off-by: Nick Dyer
> Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
> Cc: # 4.15+
> Reviewed-by: Fabio Estevam
> ---
> Changes in v4:
> - Add reviewed by Fabio
> Changes in v3:
> - Update commit message to add source of 0x4 value, fixes tag and CC stable
> Changes in v2:
> - Use hex, only alter IRQ line config
Tested on an RDU1 with Synaptics touchscreen successfully. No
interrupt store any longer...
Tested-by: Chris Healy
Re: [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
On Thu, May 17, 2018 at 12:19 PM, Nikita Yushchenko wrote: > This adds rave-sp powerbutton and backlight devices to RDU1 device tree. > > Signed-off-by: Nikita Yushchenko > --- Tested-by: Chris Healy Tested on an 8.9" RDU1.
Re: [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
On Thu, May 17, 2018 at 12:19 PM, Nikita Yushchenko wrote: > This adds rave-sp powerbutton and backlight devices to RDU1 device tree. > > Signed-off-by: Nikita Yushchenko > --- Tested-by: Chris Healy Tested on an 8.9" RDU1.
Re: [RESEND PATCH v4 0/2] ZII RAVE platform driver
Full series successfully tested on both RDU1 and RDU2 platforms. Builds and executes correctly. Tested-by: Chris Healy <cphe...@gmail.com> On Tue, Jul 25, 2017 at 11:44 AM, Andrey Smirnov <andrew.smir...@gmail.com> wrote: > Hi everyone, > > This patch series is v4 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical subsystems on RAVE > devices whose firmware implements protocol to command/qery them. > > Changes since [v3]: > > - Re-collected lost Acked-by from Rob > > - Incorporated further feedback from Andy Shevchenko > > - Dropped useless change (stray newline) to drivers/mfd/Makefile > > Changes since [v2]: > > - Fixed swapped command codes in rave_sp_common_get_boot_source() > and rave_sp_common_set_boot_source() revealed by further testing > of the code > > - Incorporated feedback from Andy Shevchenko > > Changes since [v1]: > > - Updated wording in DT-bindings as per Rob's request. > > - Collected Rob's Acked-by for patch 2/2 > > NOTE: > > * The driver for "zii,rave-sp-watchdog" exists, but I haven't >submitted it yet, becuase I wanted to make sure that API exposed by >this MFD is acceptable and doesn't need drastic changes. > > * This driver is dependent on crc_ccitt_false() introduced in >2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next' > > Feedback is greatly appreciated! > > Thanks, > Andrey Smirnov > > [v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smir...@gmail.com > [v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smir...@gmail.com > [v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smir...@gmail.com > > Andrey Smirnov (2): > platform: Add driver for RAVE Supervisory Processor > dt-bindings: mfd: Add bindings for ZII RAVE devices > > .../devicetree/bindings/mfd/zii,rave-sp.txt| 39 + > drivers/platform/Kconfig |2 + > drivers/platform/Makefile |1 + > drivers/platform/rave/Kconfig | 26 + > drivers/platform/rave/Makefile |1 + > drivers/platform/rave/rave-sp.c| 1126 > > include/linux/rave-sp.h| 54 + > 7 files changed, 1249 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt > create mode 100644 drivers/platform/rave/Kconfig > create mode 100644 drivers/platform/rave/Makefile > create mode 100644 drivers/platform/rave/rave-sp.c > create mode 100644 include/linux/rave-sp.h > > -- > 2.13.3 >
Re: [RESEND PATCH v4 0/2] ZII RAVE platform driver
Full series successfully tested on both RDU1 and RDU2 platforms. Builds and executes correctly. Tested-by: Chris Healy On Tue, Jul 25, 2017 at 11:44 AM, Andrey Smirnov wrote: > Hi everyone, > > This patch series is v4 of the driver for supervisory processor found > on RAVE series of devices from ZII. Supervisory processor is a PIC > microcontroller connected to various electrical subsystems on RAVE > devices whose firmware implements protocol to command/qery them. > > Changes since [v3]: > > - Re-collected lost Acked-by from Rob > > - Incorporated further feedback from Andy Shevchenko > > - Dropped useless change (stray newline) to drivers/mfd/Makefile > > Changes since [v2]: > > - Fixed swapped command codes in rave_sp_common_get_boot_source() > and rave_sp_common_set_boot_source() revealed by further testing > of the code > > - Incorporated feedback from Andy Shevchenko > > Changes since [v1]: > > - Updated wording in DT-bindings as per Rob's request. > > - Collected Rob's Acked-by for patch 2/2 > > NOTE: > > * The driver for "zii,rave-sp-watchdog" exists, but I haven't >submitted it yet, becuase I wanted to make sure that API exposed by >this MFD is acceptable and doesn't need drastic changes. > > * This driver is dependent on crc_ccitt_false() introduced in >2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next' > > Feedback is greatly appreciated! > > Thanks, > Andrey Smirnov > > [v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smir...@gmail.com > [v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smir...@gmail.com > [v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smir...@gmail.com > > Andrey Smirnov (2): > platform: Add driver for RAVE Supervisory Processor > dt-bindings: mfd: Add bindings for ZII RAVE devices > > .../devicetree/bindings/mfd/zii,rave-sp.txt| 39 + > drivers/platform/Kconfig |2 + > drivers/platform/Makefile |1 + > drivers/platform/rave/Kconfig | 26 + > drivers/platform/rave/Makefile |1 + > drivers/platform/rave/rave-sp.c| 1126 > > include/linux/rave-sp.h| 54 + > 7 files changed, 1249 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt > create mode 100644 drivers/platform/rave/Kconfig > create mode 100644 drivers/platform/rave/Makefile > create mode 100644 drivers/platform/rave/rave-sp.c > create mode 100644 include/linux/rave-sp.h > > -- > 2.13.3 >
Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor
On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov <andrew.smir...@gmail.com> wrote: > Add a driver for RAVE Supervisory Processor, an MCU implementing > varoius bits of housekeeping functionality (watchdoging, backlight > control, LED control, etc) on RAVE family of products by Zodiac > Inflight Innovations. > > This driver implementes core MFD/serdev device as well as > communication subroutines necessary for commanding the device. > > Cc: cphe...@gmail.com > Cc: Lucas Stach <l.st...@pengutronix.de> > Cc: Nikita Yushchenko <nikita.yo...@cogentembedded.com> > Cc: Rob Herring <robh...@kernel.org> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrey Smirnov <andrew.smir...@gmail.com> > --- > > Changes since [v1]: > > - Fix MODULE_LICENSE to specify "GPL v2" > > - Fix a bug in rave_sp_get_status() > > - Use %zu to fix warning repored by kbuild test robot > > - Remove "status" properties from examples zii,rave-sp.txt as well as >clarify the fact that device node is expected to be a child of a >serial device node > > NOTE: > > * The driver for "zii,rave-sp-watchdog" exists, but I haven't >submitted it yet, becuase I wanted to make sure that API exposed by >this MFD is acceptable and doesn't need drastic changes > > * This driver is dependent on crc_ccitt_false() introduced in >2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next' > > > [v1] lkml.kernel.org/r/20170606180643.14258-1-andrew.smir...@gmail.com > > > .../devicetree/bindings/mfd/zii,rave-sp.txt| 36 + > drivers/mfd/Kconfig|9 + > drivers/mfd/Makefile |1 + > drivers/mfd/rave-sp.c | 1009 > > include/linux/rave-sp.h| 54 ++ > 5 files changed, 1109 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt > create mode 100644 drivers/mfd/rave-sp.c > create mode 100644 include/linux/rave-sp.h > This patch was tested on Zodiac RDU1 and RDU2 platforms. Tested-by: Chris Healy <cphe...@gmail.com>
Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor
On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov wrote: > Add a driver for RAVE Supervisory Processor, an MCU implementing > varoius bits of housekeeping functionality (watchdoging, backlight > control, LED control, etc) on RAVE family of products by Zodiac > Inflight Innovations. > > This driver implementes core MFD/serdev device as well as > communication subroutines necessary for commanding the device. > > Cc: cphe...@gmail.com > Cc: Lucas Stach > Cc: Nikita Yushchenko > Cc: Rob Herring > Cc: Mark Rutland > Cc: devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Andrey Smirnov > --- > > Changes since [v1]: > > - Fix MODULE_LICENSE to specify "GPL v2" > > - Fix a bug in rave_sp_get_status() > > - Use %zu to fix warning repored by kbuild test robot > > - Remove "status" properties from examples zii,rave-sp.txt as well as >clarify the fact that device node is expected to be a child of a >serial device node > > NOTE: > > * The driver for "zii,rave-sp-watchdog" exists, but I haven't >submitted it yet, becuase I wanted to make sure that API exposed by >this MFD is acceptable and doesn't need drastic changes > > * This driver is dependent on crc_ccitt_false() introduced in >2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next' > > > [v1] lkml.kernel.org/r/20170606180643.14258-1-andrew.smir...@gmail.com > > > .../devicetree/bindings/mfd/zii,rave-sp.txt| 36 + > drivers/mfd/Kconfig|9 + > drivers/mfd/Makefile |1 + > drivers/mfd/rave-sp.c | 1009 > > include/linux/rave-sp.h| 54 ++ > 5 files changed, 1109 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt > create mode 100644 drivers/mfd/rave-sp.c > create mode 100644 include/linux/rave-sp.h > This patch was tested on Zodiac RDU1 and RDU2 platforms. Tested-by: Chris Healy
Re: Fw: [PATCH/RFC] iio: hi8435: do not enable all events by default
On Sun, May 28, 2017 at 9:50 AM, Chris Healy <chris.he...@zii.aero> wrote: > > > > > From: Jonathan Cameron <ji...@kernel.org> > Sent: Sunday, May 28, 2017 8:48 AM > To: Nikita Yoush > Cc: Hartmut Knaack; Lars-Peter Clausen; Peter Meerwald-Stadler; Sanchayan > Maity; Gregor Boirie; Matt Ranostay; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Chris Healy; Jeff White; Vladimir Barinov > Subject: Re: [PATCH/RFC] iio: hi8435: do not enable all events by default > > On Thu, 25 May 2017 08:47:47 +0300 > Nikita Yushchenko <nikita.yo...@cogentembedded.com> wrote: > >> 24.05.2017 22:27, Jonathan Cameron wrote: >> > On Tue, 23 May 2017 11:08:30 +0300 >> > Nikita Yushchenko <nikita.yo...@cogentembedded.com> wrote: >> > >> >> Having all events enabled by default is misleading. >> >> Userspace should explicitly enable events they want to receive. >> >> >> >> Signed-off-by: Nikita Yushchenko <nikita.yo...@cogentembedded.com> >> > I agree in principle, but this is a userspace ABI change. Sadly we >> > can't do it with out risking breaking userspace code... >> > >> > One of those we should have caught in review, but now it's there >> > we can't actually do anything about it unless we are absolutely >> > sure no one will notice! >> >> I see your point. >> >> Still, isn't there subsystem-level default that all events are disabled >> by default? If such, then current hi8435 state breaks subsystem-level >> rules, which is a [userspace-visible] bug. I'm not sure how far should >> we go in bug compatibility. > It is indeed the subsystem default (as much as we have one) > > This is a moderately obscure chip for linux systems, do we have a good > handle > on where it is being used - i.e. are most of the devices under control of > people we can discuss this with? The company I work for funded the initial work to get support for the this Holt HI-8435 upstream. We are presently using this driver and can accommodate this proposed userspace ABI change as we can adjust userspace if the ABI changes. Unfortunately, this doesn't answer the question of the drivers adoption elsewhere. >> >> One crazy idea could be - make default selectable via device tree (with >> default set to all-enabled to keep bug-compatibility). But perhaps >> that's over-reaction. > Yeah, wouldn't fly with the devicetree binding maintainers.. > > Jonathan > > > > > This email and any files transmitted with it are confidential & proprietary > to Zodiac Inflight Innovations. This information is intended solely for the > use of the individual or entity to which it is addressed. Access or > transmittal of the information contained in this e-mail, in full or in part, > to any other organization or persons is not authorized.
Re: Fw: [PATCH/RFC] iio: hi8435: do not enable all events by default
On Sun, May 28, 2017 at 9:50 AM, Chris Healy wrote: > > > > > From: Jonathan Cameron > Sent: Sunday, May 28, 2017 8:48 AM > To: Nikita Yoush > Cc: Hartmut Knaack; Lars-Peter Clausen; Peter Meerwald-Stadler; Sanchayan > Maity; Gregor Boirie; Matt Ranostay; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Chris Healy; Jeff White; Vladimir Barinov > Subject: Re: [PATCH/RFC] iio: hi8435: do not enable all events by default > > On Thu, 25 May 2017 08:47:47 +0300 > Nikita Yushchenko wrote: > >> 24.05.2017 22:27, Jonathan Cameron wrote: >> > On Tue, 23 May 2017 11:08:30 +0300 >> > Nikita Yushchenko wrote: >> > >> >> Having all events enabled by default is misleading. >> >> Userspace should explicitly enable events they want to receive. >> >> >> >> Signed-off-by: Nikita Yushchenko >> > I agree in principle, but this is a userspace ABI change. Sadly we >> > can't do it with out risking breaking userspace code... >> > >> > One of those we should have caught in review, but now it's there >> > we can't actually do anything about it unless we are absolutely >> > sure no one will notice! >> >> I see your point. >> >> Still, isn't there subsystem-level default that all events are disabled >> by default? If such, then current hi8435 state breaks subsystem-level >> rules, which is a [userspace-visible] bug. I'm not sure how far should >> we go in bug compatibility. > It is indeed the subsystem default (as much as we have one) > > This is a moderately obscure chip for linux systems, do we have a good > handle > on where it is being used - i.e. are most of the devices under control of > people we can discuss this with? The company I work for funded the initial work to get support for the this Holt HI-8435 upstream. We are presently using this driver and can accommodate this proposed userspace ABI change as we can adjust userspace if the ABI changes. Unfortunately, this doesn't answer the question of the drivers adoption elsewhere. >> >> One crazy idea could be - make default selectable via device tree (with >> default set to all-enabled to keep bug-compatibility). But perhaps >> that's over-reaction. > Yeah, wouldn't fly with the devicetree binding maintainers.. > > Jonathan > > > > > This email and any files transmitted with it are confidential & proprietary > to Zodiac Inflight Innovations. This information is intended solely for the > use of the individual or entity to which it is addressed. Access or > transmittal of the information contained in this e-mail, in full or in part, > to any other organization or persons is not authorized.
Re: [PATCH v5 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts
> diff --git a/drivers/mtd/devices/mtd_dataflash.c > b/drivers/mtd/devices/mtd_dataflash.c > index f9e9bd1..a566231 100644 > --- a/drivers/mtd/devices/mtd_dataflash.c > +++ b/drivers/mtd/devices/mtd_dataflash.c > @@ -84,7 +84,7 @@ > > On a Freescale i.MX51 SoC I tested this full patchset with both the AT45DB642D and AT45DB641E SPI NOR devices. Both were correctly identified: With AT45DB642D part: [2.560788] mtd_dataflash spi0.1: at45db642d (8192 KBytes) pagesize 1024 bytes (OTP) With AT45DB641E part: [2.572970] mtd_dataflash spi0.1: at45db641e (8192 KBytes) pagesize 256 bytes (OTP) Tested-by: Chris Healy <cphe...@gmail.com>
Re: [PATCH v5 1/6] mtd: dataflash: Replace C99 types with their kernel counterparts
> diff --git a/drivers/mtd/devices/mtd_dataflash.c > b/drivers/mtd/devices/mtd_dataflash.c > index f9e9bd1..a566231 100644 > --- a/drivers/mtd/devices/mtd_dataflash.c > +++ b/drivers/mtd/devices/mtd_dataflash.c > @@ -84,7 +84,7 @@ > > On a Freescale i.MX51 SoC I tested this full patchset with both the AT45DB642D and AT45DB641E SPI NOR devices. Both were correctly identified: With AT45DB642D part: [2.560788] mtd_dataflash spi0.1: at45db642d (8192 KBytes) pagesize 1024 bytes (OTP) With AT45DB641E part: [2.572970] mtd_dataflash spi0.1: at45db641e (8192 KBytes) pagesize 256 bytes (OTP) Tested-by: Chris Healy
Re: [PATCH] lib/crc-ccitt: add CCITT-FALSE CRC16 variant
On Thu, Apr 13, 2017 at 7:29 AM, Andrey Smirnov <andrew.smir...@gmail.com> wrote: > From: Andrey Vostrikov <andrey.vostri...@cogentembedded.com> > > Cc: cphe...@gmail.com > Cc: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Andrey Vostrikov <andrey.vostri...@cogentembedded.com> > Signed-off-by: Andrey Smirnov <andrew.smir...@gmail.com> > --- > include/linux/crc-ccitt.h | 7 ++ > lib/crc-ccitt.c | 58 > ++- > 2 files changed, 64 insertions(+), 1 deletion(-) > In support of a soon to be published MFD driver using serdev to talk to a supervisory processor that uses the CCITT-FALSE CRC16 variant in it's protocol, this patch was tested successfully on an i.MX6 ARM platform. Tested-by: Chris Healy <cphe...@gmail.com>
Re: [PATCH] lib/crc-ccitt: add CCITT-FALSE CRC16 variant
On Thu, Apr 13, 2017 at 7:29 AM, Andrey Smirnov wrote: > From: Andrey Vostrikov > > Cc: cphe...@gmail.com > Cc: Andrew Morton > Signed-off-by: Andrey Vostrikov > Signed-off-by: Andrey Smirnov > --- > include/linux/crc-ccitt.h | 7 ++ > lib/crc-ccitt.c | 58 > ++- > 2 files changed, 64 insertions(+), 1 deletion(-) > In support of a soon to be published MFD driver using serdev to talk to a supervisory processor that uses the CCITT-FALSE CRC16 variant in it's protocol, this patch was tested successfully on an i.MX6 ARM platform. Tested-by: Chris Healy
Re: [PATCH v2] Input: synaptics-rmi4 - stop scanning PDT after two empty pages
On Tue, Oct 25, 2016 at 1:36 PM, Nick Dyer <n...@shmanahar.org> wrote:
> We have encountered some RMI4 firmwares where there are blank pages in
> between PDT pages which contain functions. This change makes them
> correctly enumerate all functions on the device.
>
> Tested on S7817 (has empty page 2).
>
> Signed-off-by: Nick Dyer <n...@shmanahar.org>
> ---
> drivers/input/rmi4/rmi_driver.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index 4a88312..425bd19 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -422,6 +422,7 @@ static void rmi_driver_copy_pdt_to_fd(const struct
> pdt_entry *pdt,
>
> static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
> int page,
> +int *empty_pages,
> void *ctx,
> int (*callback)(struct rmi_device *rmi_dev,
> void *ctx,
> @@ -449,7 +450,16 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
> return retval;
> }
>
> - return (data->f01_bootloader_mode || addr == pdt_start) ?
> + /*
> +* Count number of empty PDT pages. If a gap of two pages
> +* or more is found, stop scanning.
> +*/
> + if (addr == pdt_start)
> + ++*empty_pages;
> + else
> + *empty_pages = 0;
> +
> + return (data->f01_bootloader_mode || *empty_pages >= 2) ?
> RMI_SCAN_DONE : RMI_SCAN_CONTINUE;
> }
>
> @@ -459,10 +469,12 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev,
> void *ctx,
> const struct pdt_entry *entry))
> {
> int page;
> + int empty_pages = 0;
> int retval = RMI_SCAN_DONE;
>
> for (page = 0; page <= RMI4_MAX_PAGE; page++) {
> - retval = rmi_scan_pdt_page(rmi_dev, page, ctx, callback);
> + retval = rmi_scan_pdt_page(rmi_dev, page, _pages,
> + ctx, callback);
> if (retval != RMI_SCAN_CONTINUE)
> break;
> }
> --
> 2.7.4
>
Tested successfully on S7817 and S7300 Synaptics touch controllers.
The S7300 has no regressions and the S7817 now shows fn55 in the
sysfs. (It did not show fn55 before the patch.)
Tested-by: Chris Healy <cphe...@gmail.com>
Re: [PATCH v2] Input: synaptics-rmi4 - stop scanning PDT after two empty pages
On Tue, Oct 25, 2016 at 1:36 PM, Nick Dyer wrote:
> We have encountered some RMI4 firmwares where there are blank pages in
> between PDT pages which contain functions. This change makes them
> correctly enumerate all functions on the device.
>
> Tested on S7817 (has empty page 2).
>
> Signed-off-by: Nick Dyer
> ---
> drivers/input/rmi4/rmi_driver.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index 4a88312..425bd19 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -422,6 +422,7 @@ static void rmi_driver_copy_pdt_to_fd(const struct
> pdt_entry *pdt,
>
> static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
> int page,
> +int *empty_pages,
> void *ctx,
> int (*callback)(struct rmi_device *rmi_dev,
> void *ctx,
> @@ -449,7 +450,16 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
> return retval;
> }
>
> - return (data->f01_bootloader_mode || addr == pdt_start) ?
> + /*
> +* Count number of empty PDT pages. If a gap of two pages
> +* or more is found, stop scanning.
> +*/
> + if (addr == pdt_start)
> + ++*empty_pages;
> + else
> + *empty_pages = 0;
> +
> + return (data->f01_bootloader_mode || *empty_pages >= 2) ?
> RMI_SCAN_DONE : RMI_SCAN_CONTINUE;
> }
>
> @@ -459,10 +469,12 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev,
> void *ctx,
> const struct pdt_entry *entry))
> {
> int page;
> + int empty_pages = 0;
> int retval = RMI_SCAN_DONE;
>
> for (page = 0; page <= RMI4_MAX_PAGE; page++) {
> - retval = rmi_scan_pdt_page(rmi_dev, page, ctx, callback);
> + retval = rmi_scan_pdt_page(rmi_dev, page, _pages,
> + ctx, callback);
> if (retval != RMI_SCAN_CONTINUE)
> break;
> }
> --
> 2.7.4
>
Tested successfully on S7817 and S7300 Synaptics touch controllers.
The S7300 has no regressions and the S7817 now shows fn55 in the
sysfs. (It did not show fn55 before the patch.)
Tested-by: Chris Healy
Re: [PATCH v8 0/10] Output raw touch data via V4L2
test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 4: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 1: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 2: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 3: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 4: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Total: 141, Succeeded: 141, Failed: 0, Warnings: 0 On Wed, Jul 20, 2016 at 12:48 AM, Hans Verkuil <hverk...@xs4all.nl> wrote: > Hi Nick, > > This series looks good. I plan on taking it for 4.9. I have to wait until > 4.8-rc1 is out and merged in our media_tree repo before I can make the pull > request, probably in about 3 weeks from now. > > One request: can you post the 'v4l2-compliance -a -f' output, using the latest > v4l2-compliance code with your patch on top. > > I'd like to make sure all input and format combinations are working as they > should. > > Regards, > > Hans > > On 07/18/2016 11:10 PM, Nick Dyer wrote: >> This is a series of patches to add output of raw touch diagnostic data via >> V4L2 >> to the Atmel maXTouch and Synaptics RMI4 drivers. >> >> It's a rewrite of the previous implementation which output via debugfs: it >> now >> uses a V4L2 device in a similar way to the sur40 driver. >> >> We have a utility which can read the data and display it in a useful format: >> https://github.com/ndyer/heatmap/commits/heatmap-v4l >> >> Changes in v8: >> - Split out docs changes, rework in RST/Sphinx, and rebase against docs-next >> - Update for changes to vb2_queue alloc_ctxs >> - Rebase against git://linuxtv.org/media_tree.git and re-test >> >> Changes in v7: >> - Tested by Andrew Duggan and Chris Healy. >> - Update bus_info to add "rmi4:" bus. >> - Fix code style issues in sur40 changes. >> >> Changes in v6: >> - Remove BUF_TYPE_TOUCH_CAPTURE, as discussed with Hans V touch devices will >> use BUF_TYPE_VIDEO_CAPTURE. >> - Touch devices should now register CAP_VIDEO_CAPTURE: CAP_TOUCH just says >> that >> this is a touch device, not a video device, but otherwise it acts the same. >> - Add some code to v4l_s_fmt() to set sensible default values for fields not >> used by touch. >> - Improve naming/doc of RMI4 F54 report types. >> - Various minor DocBook fixes, and split to separate patch. &
Re: [PATCH v8 0/10] Output raw touch data via V4L2
test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 4: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 1: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 2: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 3: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Test input 4: Stream using all formats: test MMAP for Format TD16, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TD08, Frame Size 60x36: Stride 120, Field None: OK test MMAP for Format TU16, Frame Size 60x36: Stride 120, Field None: OK Total: 141, Succeeded: 141, Failed: 0, Warnings: 0 On Wed, Jul 20, 2016 at 12:48 AM, Hans Verkuil wrote: > Hi Nick, > > This series looks good. I plan on taking it for 4.9. I have to wait until > 4.8-rc1 is out and merged in our media_tree repo before I can make the pull > request, probably in about 3 weeks from now. > > One request: can you post the 'v4l2-compliance -a -f' output, using the latest > v4l2-compliance code with your patch on top. > > I'd like to make sure all input and format combinations are working as they > should. > > Regards, > > Hans > > On 07/18/2016 11:10 PM, Nick Dyer wrote: >> This is a series of patches to add output of raw touch diagnostic data via >> V4L2 >> to the Atmel maXTouch and Synaptics RMI4 drivers. >> >> It's a rewrite of the previous implementation which output via debugfs: it >> now >> uses a V4L2 device in a similar way to the sur40 driver. >> >> We have a utility which can read the data and display it in a useful format: >> https://github.com/ndyer/heatmap/commits/heatmap-v4l >> >> Changes in v8: >> - Split out docs changes, rework in RST/Sphinx, and rebase against docs-next >> - Update for changes to vb2_queue alloc_ctxs >> - Rebase against git://linuxtv.org/media_tree.git and re-test >> >> Changes in v7: >> - Tested by Andrew Duggan and Chris Healy. >> - Update bus_info to add "rmi4:" bus. >> - Fix code style issues in sur40 changes. >> >> Changes in v6: >> - Remove BUF_TYPE_TOUCH_CAPTURE, as discussed with Hans V touch devices will >> use BUF_TYPE_VIDEO_CAPTURE. >> - Touch devices should now register CAP_VIDEO_CAPTURE: CAP_TOUCH just says >> that >> this is a touch device, not a video device, but otherwise it acts the same. >> - Add some code to v4l_s_fmt() to set sensible default values for fields not >> used by touch. >> - Improve naming/doc of RMI4 F54 report types. >> - Various minor DocBook fixes, and split to separate patch. >> - Update my email address.
Re: [PATCH v3 0/5] Devicetree support for misc/eeprom/eeprom_93xx46.
On 11/25/2015 12:30 AM, Cory Tusar wrote: > This series of patches adds an initial set of devicetree bindings to the > eeprom_93xx46 driver which mirror the configuration options previously > available as a platform device. These bindings are then extended to > include support for specific Atmel devices in this family and also to > support GPIO-based selection of the device (e.g. for use with an SPI bus > mux). > > Additionally, an address aliasing issue with 16-bit read and write > accesses in the eeprom_93xx46 driver discovered during testing is fixed. > > Changes since v2: > - Changed node name to 'eeprom' in DT bindings example. > - Simplified several bits of return logic. > - Removed #ifdef CONFIG_OF. > - Allow compiler to handle promotion to bool return values. > - Reworked GPIO handling to use gpiod_* functions throughout (and > fixed an oversight where GPIO flags were being ignored). > > Changes since v1: > - Consolidated all Documentation/devictree additions into a single patch. > - Clarified compatible string shall be only one of the supported values. > - Renamed the 'select-gpio' binding to 'select-gpios'. > > Cory Tusar (5): > misc: eeprom_93xx46: Fix 16-bit read and write accesses. > Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver. > misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings. > misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device. > misc: eeprom_93xx46: Add support for a GPIO 'select' line. > > .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 +++ > drivers/misc/eeprom/eeprom_93xx46.c| 212 > + > include/linux/eeprom_93xx46.h | 9 + > 3 files changed, 210 insertions(+), 36 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt Entire series was... Tested-by: Chris Healy ...on a Freescale i.MX51 platform with a Microchip 93LC46A EEPROM. This email and any files transmitted with it are confidential & proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] Devicetree support for misc/eeprom/eeprom_93xx46.
On 11/25/2015 12:30 AM, Cory Tusar wrote: > This series of patches adds an initial set of devicetree bindings to the > eeprom_93xx46 driver which mirror the configuration options previously > available as a platform device. These bindings are then extended to > include support for specific Atmel devices in this family and also to > support GPIO-based selection of the device (e.g. for use with an SPI bus > mux). > > Additionally, an address aliasing issue with 16-bit read and write > accesses in the eeprom_93xx46 driver discovered during testing is fixed. > > Changes since v2: > - Changed node name to 'eeprom' in DT bindings example. > - Simplified several bits of return logic. > - Removed #ifdef CONFIG_OF. > - Allow compiler to handle promotion to bool return values. > - Reworked GPIO handling to use gpiod_* functions throughout (and > fixed an oversight where GPIO flags were being ignored). > > Changes since v1: > - Consolidated all Documentation/devictree additions into a single patch. > - Clarified compatible string shall be only one of the supported values. > - Renamed the 'select-gpio' binding to 'select-gpios'. > > Cory Tusar (5): > misc: eeprom_93xx46: Fix 16-bit read and write accesses. > Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver. > misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings. > misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device. > misc: eeprom_93xx46: Add support for a GPIO 'select' line. > > .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 +++ > drivers/misc/eeprom/eeprom_93xx46.c| 212 > + > include/linux/eeprom_93xx46.h | 9 + > 3 files changed, 210 insertions(+), 36 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt Entire series was... Tested-by: Chris Healy <chris.he...@zii.aero> ...on a Freescale i.MX51 platform with a Microchip 93LC46A EEPROM. This email and any files transmitted with it are confidential & proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM accessfunctions
Hi Guenter,
I do not believe it is possible to know if an EEPROM is attached or not.
Chris
From: Guenter Roeck [li...@roeck-us.net]
Sent: Thursday, October 23, 2014 9:40 AM
To: Andrew Lunn
Cc: net...@vger.kernel.org; David S. Miller; Florian Fainelli;
linux-kernel@vger.kernel.org; Chris Healy
Subject: Re: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM
accessfunctions
On Thu, Oct 23, 2014 at 03:54:12PM +0200, Andrew Lunn wrote:
> On Wed, Oct 22, 2014 at 09:03:18PM -0700, Guenter Roeck wrote:
> > MV88E6352 supports read and write access to its configuration eeprom.
>
> Hi Guenter
>
> I don't have the datasheet for the MV88E6352. Is the EEPROM built in,
> or external on an i2c bus?
>
External.
> > +static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
> > +{
> > + return 0x200;
> > +}
>
> How do you handle the case of it being external and not populated.
> Would it not be better to try to detect it here, and return 0 if it
> does not exist?
>
Makes sense, if it is detectable that it the EEPROM not there. Browsing
through the datasheet, I don't see how I could detect it; there does not
seem to be a status bit indicating if the EEPROM is there or not. There
are sw_mode pins which determine if the eeprom should be loaded after
reset or not, but I don't see anything in the register set which would
tell me.
Chris, do you know if there is a means to detect if the EEPROM is present
on the MV88E6352 ?
Thanks,
Guenter
This email and any files transmitted with it are confidential & proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM accessfunctions
Hi Guenter,
I do not believe it is possible to know if an EEPROM is attached or not.
Chris
From: Guenter Roeck [li...@roeck-us.net]
Sent: Thursday, October 23, 2014 9:40 AM
To: Andrew Lunn
Cc: net...@vger.kernel.org; David S. Miller; Florian Fainelli;
linux-kernel@vger.kernel.org; Chris Healy
Subject: Re: [PATCH 10/14] net: dsa/mv88e6352: Implement EEPROM
accessfunctions
On Thu, Oct 23, 2014 at 03:54:12PM +0200, Andrew Lunn wrote:
On Wed, Oct 22, 2014 at 09:03:18PM -0700, Guenter Roeck wrote:
MV88E6352 supports read and write access to its configuration eeprom.
Hi Guenter
I don't have the datasheet for the MV88E6352. Is the EEPROM built in,
or external on an i2c bus?
External.
+static int mv88e6352_get_eeprom_len(struct dsa_switch *ds)
+{
+ return 0x200;
+}
How do you handle the case of it being external and not populated.
Would it not be better to try to detect it here, and return 0 if it
does not exist?
Makes sense, if it is detectable that it the EEPROM not there. Browsing
through the datasheet, I don't see how I could detect it; there does not
seem to be a status bit indicating if the EEPROM is there or not. There
are sw_mode pins which determine if the eeprom should be loaded after
reset or not, but I don't see anything in the register set which would
tell me.
Chris, do you know if there is a means to detect if the EEPROM is present
on the MV88E6352 ?
Thanks,
Guenter
This email and any files transmitted with it are confidential proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
On Tue, Apr 15, 2014 at 07:16:40PM -0700, Guenter Roeck wrote: > This simplifies error path and deinit/removal functions. > > Signed-off-by: Guenter Roeck Tested-by: Chris Healy This email and any files transmitted with it are confidential & proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
OK, I just sent it. Hopefully, I didn't mess it up again! Do I need to do the same for 2/3 and 3/3? From: Chris Healy Sent: Wednesday, April 16, 2014 11:48 AM To: Guenter Roeck; Florian Fainelli Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org Subject: RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible On Tue, Apr 15, 2014 at 07:16:40PM -0700, Guenter Roeck wrote: > This simplifies error path and deinit/removal functions. > > Signed-off-by: Guenter Roeck Tested-by: Chris Healy This email and any files transmitted with it are confidential & proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
OK, I just sent it. Hopefully, I didn't mess it up again! Do I need to do the same for 2/3 and 3/3? From: Chris Healy Sent: Wednesday, April 16, 2014 11:48 AM To: Guenter Roeck; Florian Fainelli Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org Subject: RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible On Tue, Apr 15, 2014 at 07:16:40PM -0700, Guenter Roeck wrote: This simplifies error path and deinit/removal functions. Signed-off-by: Guenter Roeck li...@roeck-us.net Tested-by: Chris Healy cphe...@gmail.com This email and any files transmitted with it are confidential proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
On Tue, Apr 15, 2014 at 07:16:40PM -0700, Guenter Roeck wrote: This simplifies error path and deinit/removal functions. Signed-off-by: Guenter Roeck li...@roeck-us.net Tested-by: Chris Healy cphe...@gmail.com This email and any files transmitted with it are confidential proprietary to Systems and Software Enterprises, LLC. This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/3] net: mdio-gpio: Add support for separate MDI and MDO gpio pins
This is for a system with fixed assignments of input and output pins
(various variants of Kontron COMe).
Signed-off-by: Guenter Roeck
Tested-by: Chris Healy
---
drivers/net/phy/mdio-gpio.c | 34 +++---
include/linux/mdio-gpio.h |2 ++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index fac211a..9c4defd 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -32,8 +32,8 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
- int mdc, mdio;
- int mdc_active_low, mdio_active_low;
+ int mdc, mdio, mdo;
+ int mdc_active_low, mdio_active_low, mdo_active_low;
};
static void *mdio_gpio_of_get_data(struct platform_device *pdev)
@@ -60,6 +60,12 @@ static void *mdio_gpio_of_get_data(struct platform_device
*pdev)
pdata->mdio = ret;
pdata->mdio_active_low = flags & OF_GPIO_ACTIVE_LOW;
+ ret = of_get_gpio_flags(np, 2, );
+ if (ret > 0) {
+ pdata->mdo = ret;
+ pdata->mdo_active_low = flags & OF_GPIO_ACTIVE_LOW;
+ }
+
return pdata;
}
@@ -68,6 +74,16 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
+ if (bitbang->mdo) {
+ /* Separate output pin. Always set its value to high
+* when changing direction. If direction is input,
+* assume the pin serves as pull-up. If direction is
+* output, the default value is high.
+*/
+ gpio_set_value(bitbang->mdo, 1 ^ bitbang->mdo_active_low);
+ return;
+ }
+
if (dir)
gpio_direction_output(bitbang->mdio,
1 ^ bitbang->mdio_active_low);
@@ -88,7 +104,10 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang->mdio, what ^ bitbang->mdio_active_low);
+ if (bitbang->mdo)
+ gpio_set_value(bitbang->mdo, what ^ bitbang->mdo_active_low);
+ else
+ gpio_set_value(bitbang->mdio, what ^ bitbang->mdio_active_low);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -125,6 +144,8 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
bitbang->mdc_active_low = pdata->mdc_active_low;
bitbang->mdio = pdata->mdio;
bitbang->mdio_active_low = pdata->mdio_active_low;
+ bitbang->mdo = pdata->mdo;
+ bitbang->mdo_active_low = pdata->mdo_active_low;
new_bus = alloc_mdio_bitbang(>ctrl);
if (!new_bus)
@@ -151,6 +172,13 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
if (devm_gpio_request(dev, bitbang->mdio, "mdio"))
goto out_free_bus;
+ if (bitbang->mdo) {
+ if (devm_gpio_request(dev, bitbang->mdo, "mdo"))
+ goto out_free_bus;
+ gpio_direction_output(bitbang->mdo, 1);
+ gpio_direction_input(bitbang->mdio);
+ }
+
gpio_direction_output(bitbang->mdc, 0);
dev_set_drvdata(dev, new_bus);
diff --git a/include/linux/mdio-gpio.h b/include/linux/mdio-gpio.h
index 57e57fe..66c30a7 100644
--- a/include/linux/mdio-gpio.h
+++ b/include/linux/mdio-gpio.h
@@ -17,9 +17,11 @@ struct mdio_gpio_platform_data {
/* GPIO numbers for bus pins */
unsigned int mdc;
unsigned int mdio;
+ unsigned int mdo;
bool mdc_active_low;
bool mdio_active_low;
+ bool mdo_active_low;
unsigned int phy_mask;
int irqs[PHY_MAX_ADDR];
--
1.7.9.7
This email and any files transmitted with it are confidential & proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] net: mdio-gpio: Add support for active low gpio pins
Some systems using mdio-gpio may use active-low gpio pins
(eg with inverters or FETs connected to all or some of the
gpio pins).
Signed-off-by: Guenter Roeck
Tested-by: Chris Healy
---
drivers/net/phy/mdio-gpio.c | 19 +--
include/linux/mdio-gpio.h |3 +++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index e853066..fac211a 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -33,28 +33,32 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
int mdc, mdio;
+ int mdc_active_low, mdio_active_low;
};
static void *mdio_gpio_of_get_data(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct mdio_gpio_platform_data *pdata;
+ enum of_gpio_flags flags;
int ret;
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return NULL;
- ret = of_get_gpio(np, 0);
+ ret = of_get_gpio_flags(np, 0, );
if (ret < 0)
return NULL;
pdata->mdc = ret;
+ pdata->mdc_active_low = flags & OF_GPIO_ACTIVE_LOW;
- ret = of_get_gpio(np, 1);
+ ret = of_get_gpio_flags(np, 1, );
if (ret < 0)
return NULL;
pdata->mdio = ret;
+ pdata->mdio_active_low = flags & OF_GPIO_ACTIVE_LOW;
return pdata;
}
@@ -65,7 +69,8 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
container_of(ctrl, struct mdio_gpio_info, ctrl);
if (dir)
- gpio_direction_output(bitbang->mdio, 1);
+ gpio_direction_output(bitbang->mdio,
+ 1 ^ bitbang->mdio_active_low);
else
gpio_direction_input(bitbang->mdio);
}
@@ -75,7 +80,7 @@ static int mdio_get(struct mdiobb_ctrl *ctrl)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- return gpio_get_value(bitbang->mdio);
+ return gpio_get_value(bitbang->mdio) ^ bitbang->mdio_active_low;
}
static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
@@ -83,7 +88,7 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang->mdio, what);
+ gpio_set_value(bitbang->mdio, what ^ bitbang->mdio_active_low);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -91,7 +96,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang->mdc, what);
+ gpio_set_value(bitbang->mdc, what ^ bitbang->mdc_active_low);
}
static struct mdiobb_ops mdio_gpio_ops = {
@@ -117,7 +122,9 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
bitbang->ctrl.ops = _gpio_ops;
bitbang->ctrl.reset = pdata->reset;
bitbang->mdc = pdata->mdc;
+ bitbang->mdc_active_low = pdata->mdc_active_low;
bitbang->mdio = pdata->mdio;
+ bitbang->mdio_active_low = pdata->mdio_active_low;
new_bus = alloc_mdio_bitbang(>ctrl);
if (!new_bus)
diff --git a/include/linux/mdio-gpio.h b/include/linux/mdio-gpio.h
index 7c9fe3c..57e57fe 100644
--- a/include/linux/mdio-gpio.h
+++ b/include/linux/mdio-gpio.h
@@ -18,6 +18,9 @@ struct mdio_gpio_platform_data {
unsigned int mdc;
unsigned int mdio;
+ bool mdc_active_low;
+ bool mdio_active_low;
+
unsigned int phy_mask;
int irqs[PHY_MAX_ADDR];
/* reset callback */
--
1.7.9.7
This email and any files transmitted with it are confidential & proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
This simplifies error path and deinit/removal functions.
Signed-off-by: Guenter Roeck
Tested-by: Chris Healy
---
drivers/net/phy/mdio-gpio.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index e701433..e853066 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -110,7 +110,7 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
struct mdio_gpio_info *bitbang;
int i;
- bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
+ bitbang = devm_kzalloc(dev, sizeof(*bitbang), GFP_KERNEL);
if (!bitbang)
goto out;
@@ -121,7 +121,7 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
new_bus = alloc_mdio_bitbang(>ctrl);
if (!new_bus)
- goto out_free_bitbang;
+ goto out;
new_bus->name = "GPIO Bitbanged MDIO",
@@ -138,11 +138,11 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
snprintf(new_bus->id, MII_BUS_ID_SIZE, "gpio-%x", bus_id);
- if (gpio_request(bitbang->mdc, "mdc"))
+ if (devm_gpio_request(dev, bitbang->mdc, "mdc"))
goto out_free_bus;
- if (gpio_request(bitbang->mdio, "mdio"))
- goto out_free_mdc;
+ if (devm_gpio_request(dev, bitbang->mdio, "mdio"))
+ goto out_free_bus;
gpio_direction_output(bitbang->mdc, 0);
@@ -150,12 +150,8 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
return new_bus;
-out_free_mdc:
- gpio_free(bitbang->mdc);
out_free_bus:
free_mdio_bitbang(new_bus);
-out_free_bitbang:
- kfree(bitbang);
out:
return NULL;
}
@@ -163,13 +159,8 @@ out:
static void mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
- struct mdio_gpio_info *bitbang = bus->priv;
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
- gpio_free(bitbang->mdc);
free_mdio_bitbang(bus);
- kfree(bitbang);
}
static void mdio_gpio_bus_destroy(struct device *dev)
--
1.7.9.7
This email and any files transmitted with it are confidential & proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] net: mdio-gpio: Use devm_ functions where possible
This simplifies error path and deinit/removal functions.
Signed-off-by: Guenter Roeck li...@roeck-us.net
Tested-by: Chris Healy cphe...@gmail.com
---
drivers/net/phy/mdio-gpio.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index e701433..e853066 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -110,7 +110,7 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
struct mdio_gpio_info *bitbang;
int i;
- bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
+ bitbang = devm_kzalloc(dev, sizeof(*bitbang), GFP_KERNEL);
if (!bitbang)
goto out;
@@ -121,7 +121,7 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
new_bus = alloc_mdio_bitbang(bitbang-ctrl);
if (!new_bus)
- goto out_free_bitbang;
+ goto out;
new_bus-name = GPIO Bitbanged MDIO,
@@ -138,11 +138,11 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
snprintf(new_bus-id, MII_BUS_ID_SIZE, gpio-%x, bus_id);
- if (gpio_request(bitbang-mdc, mdc))
+ if (devm_gpio_request(dev, bitbang-mdc, mdc))
goto out_free_bus;
- if (gpio_request(bitbang-mdio, mdio))
- goto out_free_mdc;
+ if (devm_gpio_request(dev, bitbang-mdio, mdio))
+ goto out_free_bus;
gpio_direction_output(bitbang-mdc, 0);
@@ -150,12 +150,8 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
return new_bus;
-out_free_mdc:
- gpio_free(bitbang-mdc);
out_free_bus:
free_mdio_bitbang(new_bus);
-out_free_bitbang:
- kfree(bitbang);
out:
return NULL;
}
@@ -163,13 +159,8 @@ out:
static void mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
- struct mdio_gpio_info *bitbang = bus-priv;
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang-mdio);
- gpio_free(bitbang-mdc);
free_mdio_bitbang(bus);
- kfree(bitbang);
}
static void mdio_gpio_bus_destroy(struct device *dev)
--
1.7.9.7
This email and any files transmitted with it are confidential proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] net: mdio-gpio: Add support for active low gpio pins
Some systems using mdio-gpio may use active-low gpio pins
(eg with inverters or FETs connected to all or some of the
gpio pins).
Signed-off-by: Guenter Roeck li...@roeck-us.net
Tested-by: Chris Healy cphe...@gmail.com
---
drivers/net/phy/mdio-gpio.c | 19 +--
include/linux/mdio-gpio.h |3 +++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index e853066..fac211a 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -33,28 +33,32 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
int mdc, mdio;
+ int mdc_active_low, mdio_active_low;
};
static void *mdio_gpio_of_get_data(struct platform_device *pdev)
{
struct device_node *np = pdev-dev.of_node;
struct mdio_gpio_platform_data *pdata;
+ enum of_gpio_flags flags;
int ret;
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return NULL;
- ret = of_get_gpio(np, 0);
+ ret = of_get_gpio_flags(np, 0, flags);
if (ret 0)
return NULL;
pdata-mdc = ret;
+ pdata-mdc_active_low = flags OF_GPIO_ACTIVE_LOW;
- ret = of_get_gpio(np, 1);
+ ret = of_get_gpio_flags(np, 1, flags);
if (ret 0)
return NULL;
pdata-mdio = ret;
+ pdata-mdio_active_low = flags OF_GPIO_ACTIVE_LOW;
return pdata;
}
@@ -65,7 +69,8 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
container_of(ctrl, struct mdio_gpio_info, ctrl);
if (dir)
- gpio_direction_output(bitbang-mdio, 1);
+ gpio_direction_output(bitbang-mdio,
+ 1 ^ bitbang-mdio_active_low);
else
gpio_direction_input(bitbang-mdio);
}
@@ -75,7 +80,7 @@ static int mdio_get(struct mdiobb_ctrl *ctrl)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- return gpio_get_value(bitbang-mdio);
+ return gpio_get_value(bitbang-mdio) ^ bitbang-mdio_active_low;
}
static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
@@ -83,7 +88,7 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang-mdio, what);
+ gpio_set_value(bitbang-mdio, what ^ bitbang-mdio_active_low);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -91,7 +96,7 @@ static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang-mdc, what);
+ gpio_set_value(bitbang-mdc, what ^ bitbang-mdc_active_low);
}
static struct mdiobb_ops mdio_gpio_ops = {
@@ -117,7 +122,9 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
bitbang-ctrl.ops = mdio_gpio_ops;
bitbang-ctrl.reset = pdata-reset;
bitbang-mdc = pdata-mdc;
+ bitbang-mdc_active_low = pdata-mdc_active_low;
bitbang-mdio = pdata-mdio;
+ bitbang-mdio_active_low = pdata-mdio_active_low;
new_bus = alloc_mdio_bitbang(bitbang-ctrl);
if (!new_bus)
diff --git a/include/linux/mdio-gpio.h b/include/linux/mdio-gpio.h
index 7c9fe3c..57e57fe 100644
--- a/include/linux/mdio-gpio.h
+++ b/include/linux/mdio-gpio.h
@@ -18,6 +18,9 @@ struct mdio_gpio_platform_data {
unsigned int mdc;
unsigned int mdio;
+ bool mdc_active_low;
+ bool mdio_active_low;
+
unsigned int phy_mask;
int irqs[PHY_MAX_ADDR];
/* reset callback */
--
1.7.9.7
This email and any files transmitted with it are confidential proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/3] net: mdio-gpio: Add support for separate MDI and MDO gpio pins
This is for a system with fixed assignments of input and output pins
(various variants of Kontron COMe).
Signed-off-by: Guenter Roeck li...@roeck-us.net
Tested-by: Chris Healy cphe...@gmail.com
---
drivers/net/phy/mdio-gpio.c | 34 +++---
include/linux/mdio-gpio.h |2 ++
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index fac211a..9c4defd 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -32,8 +32,8 @@
struct mdio_gpio_info {
struct mdiobb_ctrl ctrl;
- int mdc, mdio;
- int mdc_active_low, mdio_active_low;
+ int mdc, mdio, mdo;
+ int mdc_active_low, mdio_active_low, mdo_active_low;
};
static void *mdio_gpio_of_get_data(struct platform_device *pdev)
@@ -60,6 +60,12 @@ static void *mdio_gpio_of_get_data(struct platform_device
*pdev)
pdata-mdio = ret;
pdata-mdio_active_low = flags OF_GPIO_ACTIVE_LOW;
+ ret = of_get_gpio_flags(np, 2, flags);
+ if (ret 0) {
+ pdata-mdo = ret;
+ pdata-mdo_active_low = flags OF_GPIO_ACTIVE_LOW;
+ }
+
return pdata;
}
@@ -68,6 +74,16 @@ static void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
+ if (bitbang-mdo) {
+ /* Separate output pin. Always set its value to high
+* when changing direction. If direction is input,
+* assume the pin serves as pull-up. If direction is
+* output, the default value is high.
+*/
+ gpio_set_value(bitbang-mdo, 1 ^ bitbang-mdo_active_low);
+ return;
+ }
+
if (dir)
gpio_direction_output(bitbang-mdio,
1 ^ bitbang-mdio_active_low);
@@ -88,7 +104,10 @@ static void mdio_set(struct mdiobb_ctrl *ctrl, int what)
struct mdio_gpio_info *bitbang =
container_of(ctrl, struct mdio_gpio_info, ctrl);
- gpio_set_value(bitbang-mdio, what ^ bitbang-mdio_active_low);
+ if (bitbang-mdo)
+ gpio_set_value(bitbang-mdo, what ^ bitbang-mdo_active_low);
+ else
+ gpio_set_value(bitbang-mdio, what ^ bitbang-mdio_active_low);
}
static void mdc_set(struct mdiobb_ctrl *ctrl, int what)
@@ -125,6 +144,8 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
bitbang-mdc_active_low = pdata-mdc_active_low;
bitbang-mdio = pdata-mdio;
bitbang-mdio_active_low = pdata-mdio_active_low;
+ bitbang-mdo = pdata-mdo;
+ bitbang-mdo_active_low = pdata-mdo_active_low;
new_bus = alloc_mdio_bitbang(bitbang-ctrl);
if (!new_bus)
@@ -151,6 +172,13 @@ static struct mii_bus *mdio_gpio_bus_init(struct device
*dev,
if (devm_gpio_request(dev, bitbang-mdio, mdio))
goto out_free_bus;
+ if (bitbang-mdo) {
+ if (devm_gpio_request(dev, bitbang-mdo, mdo))
+ goto out_free_bus;
+ gpio_direction_output(bitbang-mdo, 1);
+ gpio_direction_input(bitbang-mdio);
+ }
+
gpio_direction_output(bitbang-mdc, 0);
dev_set_drvdata(dev, new_bus);
diff --git a/include/linux/mdio-gpio.h b/include/linux/mdio-gpio.h
index 57e57fe..66c30a7 100644
--- a/include/linux/mdio-gpio.h
+++ b/include/linux/mdio-gpio.h
@@ -17,9 +17,11 @@ struct mdio_gpio_platform_data {
/* GPIO numbers for bus pins */
unsigned int mdc;
unsigned int mdio;
+ unsigned int mdo;
bool mdc_active_low;
bool mdio_active_low;
+ bool mdo_active_low;
unsigned int phy_mask;
int irqs[PHY_MAX_ADDR];
--
1.7.9.7
This email and any files transmitted with it are confidential proprietary to
Systems and Software Enterprises, LLC. This information is intended solely for
the use of the individual or entity to which it is addressed. Access or
transmittal of the information contained in this e-mail, in full or in part, to
any other organization or persons is not authorized.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
