[PATCH mfd+gpio 1/2] drivers: mfd: Add support for Moxtet bus
On the Turris Mox router there can be connected different modules to
the main CPU board, currently a module with a SFP cage, a module with
MiniPCIe connector, a 4-port switch module and a 8-port switch module,
for example:
[CPU]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these
are connected via SPI to CPU board.
Via this SPI connection we are able to discover which modules are
connected and we can also read/write some configuration to the modules.
Fromi/to each module 8 bits can be read (of which lower 4 bits identify
the module) and written.
For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.
Other modules may support something else.
This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them, for example a gpio driver for the
module with a SFP cage.
The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.
Signed-off-by: Marek Behún
---
Documentation/devicetree/bindings/mfd/moxtet.txt | 36 ++
MAINTAINERS | 7 +
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/moxtet.c | 501 +++
include/linux/mfd/moxtet.h | 103 +
6 files changed, 658 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/moxtet.txt
create mode 100644 drivers/mfd/moxtet.c
create mode 100644 include/linux/mfd/moxtet.h
diff --git a/Documentation/devicetree/bindings/mfd/moxtet.txt
b/Documentation/devicetree/bindings/mfd/moxtet.txt
new file mode 100644
index ..02b96fbd5ddd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/moxtet.txt
@@ -0,0 +1,36 @@
+Turris Mox module configuration bus (over SPI)
+
+Required properties:
+ - compatible : Should be "cznic,moxtet".
+ - #address-cells : Has to be 1
+ - #size-cells : Has to be 0
+For other required and optional properties of SPI slave
+nodes please refer to ../spi/spi-bus.txt.
+
+Required properties of subnodes:
+ - reg : Should be position on the Moxtet bus
+ - moxtet,id : Should be ID of the Moxtet device connected
+
+The driver finds the devices connected to the bus by itself, but it may be
+needed to reference some of them from other parts of the device tree. In that
+case the devices can be defined as subnodes of the moxtet node.
+
+Example:
+
+ moxtet@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cznic,moxtet";
+ reg = <1>;
+ spi-max-frequency = <100>;
+ spi-cpol;
+ spi-cpha;
+
+ moxtet_sfp: moxtet-sfp@0 {
+ compatible = "cznic,moxtet-sfp";
+ gpio-controller;
+ #gpio-cells;
+ reg = <0>;
+ moxtet,id = <1>;
+ }
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b25905..84e60ee83951 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1412,6 +1412,13 @@ F: drivers/clocksource/timer-prima2.c
F: drivers/clocksource/timer-atlas7.c
N: [^a-z]sirf
+ARM/CZ.NIC TURRIS MOX SUPPORT
+M: Marek Behun
+W: http://mox.turris.cz
+S: Maintained
+F: include/mfd/moxtet.h
+F: drivers/mfd/moxtet.c
+
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 11841f4b7b2b..cb401841e2ac 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -814,6 +814,16 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MOXTET
+ tristate "CZ.NIC Turris Mox module configuration bus"
+ depends on SPI_MASTER && OF
+ help
+ Say yes here to add support for the module configuration bus found
+ on CZ.NIC's Turris Mox. This is needed for the ability to read
+ in what order the modules are connected and to get/set some of
+ their settings. For example the GPIOs on Mox SFP module are
+ configured through this bus.
+
config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5856a9489cbd..338ecf311911 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -159,6 +159,7 @@ max8925-objs:= max8925-core.o
max8925-i2c.o
[PATCH mfd+gpio 2/2] drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one
device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
Signed-off-by: Marek Behún
---
.../devicetree/bindings/gpio/gpio-moxtet.txt | 31 +++
MAINTAINERS| 1 +
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-moxtet.c | 209 +
5 files changed, 251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
create mode 100644 drivers/gpio/gpio-moxtet.c
diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
new file mode 100644
index ..64a9a1bfd4cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
@@ -0,0 +1,31 @@
+Turris Mox Moxtet GPIO expander
+
+Required properties:
+ - compatible : Should be "cznic,moxtet-gpio".
+ - gpio-controller : Marks the device node as a GPIO controller.
+ - #gpio-cells : Should be two. For consumer use see gpio.txt.
+ - moxtet,input-mask : Bitmask. Those bits which correspond to input GPIOs
+ when read from Moxtet bus should be set here.
+ For example if bit 0 and bit 3 are input GPIO bits,
+ this should be set to 0x9.
+ Since there are only 4 input bits, 0xf is max value.
+ - moxtet,output-mask : Bitmask. Those bits which correspond to output GPIOs
+ when written to Moxtet bus should be set here.
+ For example if bit 1 and bit 6 are output GPIO bits,
+ this should be set to 0x41.
+ Since there are at most 8 output bits, 0xff is max
+ value.
+Other properties are required for a moxtet bus device, please refer to
+Documentation/devicetree/bindings/mfd/moxtet.txt.
+
+Example:
+
+ moxtet_sfp: moxtet-sfp@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells;
+ reg = <0>;
+ moxtet,id = <1>;
+ moxtet,input-mask = <0x7>;
+ moxtet,output-mask = <0x3>;
+ }
diff --git a/MAINTAINERS b/MAINTAINERS
index 84e60ee83951..0ca4e5302054 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1417,6 +1417,7 @@ M:Marek Behun
W: http://mox.turris.cz
S: Maintained
F: include/mfd/moxtet.h
+F: drivers/gpio/gpio-moxtet.c
F: drivers/mfd/moxtet.c
ARM/EBSA110 MACHINE SUPPORT
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b8cbf5081389..2c0202aa91d0 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1055,6 +1055,15 @@ config GPIO_MAX77620
driver also provides interrupt support for each of the gpios.
Say yes here to enable the max77620 to be used as gpio controller.
+config GPIO_MOXTET
+ tristate "Turris Mox Moxtet bus GPIO expander"
+ depends on MFD_MOXTET
+ help
+ Say yes here if you are building for the Turris Mox router.
+ This is the driver needed for configuring the GPIOs via the Moxtet
+ bus. For example the Mox module with SFP cage needs this driver
+ so that phylink can use corresponding GPIOs.
+
config GPIO_MSIC
bool "Intel MSIC mixed signal gpio support"
depends on (X86 || COMPILE_TEST) && MFD_INTEL_MSIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 80d58c2de730..e119b3b87f1f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
+obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxtet.c b/drivers/gpio/gpio-moxtet.c
new file mode 100644
index ..d0b50581118d
--- /dev/null
+++ b/drivers/gpio/gpio-moxtet.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox Moxtet GPIO expander
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct moxtet_gpio_chip {
+ struct device *dev;
+ struct gpio_chipgpio_chip;
+ u8 in_mask;
+ u8 out_mask;
+};
+
+static int moxtet_gpio_dir_mask(struct gpio_chip *gc, unsigned int offset,
+ int *dir, u8 *mask)
+{
+ struct moxtet_gpio_chip *chip = gpio
[PATCH mvebu-dt64] arm64: dts: marvell: armada-37xx: Add DTS file for Turris Mox
This adds support for the Turris Mox board from CZ.NIC.
Turris Mox is as modular router based on the Armada 3720 SOC (same as
EspressoBin).
The basic module can be extended by different modules.
When those modules are connected, U-Boot shall patch this device-tree
by enabling nodes corresponding to those modules.
Signed-off-by: Marek Behún
---
.../arm/marvell/armada-3720-turris-mox.txt | 6 +
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../boot/dts/marvell/armada-3720-turris-mox.dts| 817 +
3 files changed, 824 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
diff --git
a/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
b/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
new file mode 100644
index ..408fc07a9bbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
@@ -0,0 +1,6 @@
+CZ.NIC's Turris Mox SOHO router Device Tree Bindings
+
+
+Required root node property:
+
+compatible: must contain "cznic,turris-mox"
diff --git a/arch/arm64/boot/dts/marvell/Makefile
b/arch/arm64/boot/dts/marvell/Makefile
index ea9d49f2a911..1dd89d1bf8ad 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -2,6 +2,7 @@
# Mvebu SoC Family
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-turris-mox.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
new file mode 100644
index ..9267ae96f14f
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -0,0 +1,817 @@
+// SPDX-License-Identifier: GPL-2.0+ or X11
+/*
+ * Device Tree file for CZ.NIC Turris Mox Board
+ * 2018 by Marek Behun
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "armada-372x.dtsi"
+
+/ {
+ model = "CZ.NIC Turris Mox Board";
+ compatible = "cznic,turris-mox", "marvell,armada3720",
+"marvell,armada3710";
+
+ aliases {
+ spi0 = &spi0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x 0x 0x2000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ red {
+ gpios = <&gpiosb 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ reset_button {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpiosb 20 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ exp_usb3_vbus: usb3-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb3-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ regulator-always-on;
+ gpio = <&gpiosb 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&exp_usb3_vbus>;
+ };
+
+ vsdc_reg: vsdc_reg {
+ compatible = "regulator-gpio";
+ regulator-name = "vsdc";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+
+ gpios = <&gpiosb 23 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+ states = <180 0x1
+ 330 0x0>;
+ enable-active-high;
+ };
+
+ vsdio_reg: vsdio_reg {
+ compatible = "regulator-gpio";
+ regulator-name = "vsdio";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+
+ gpios = <&gpiosb 22 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+ states = <180 0x1
+
[PATCH RFC] ARM64: dts: marvell: Add DTS file for Turris Mox
This is a RFC, please do not merge.
This adds basic support for the Turris Mox board from CZ.NIC.
Turris Mox is as modular router based on the Armada 3720 SOC (same as
EspressoBin).
The basic module can be extended by different modules.
When those modules are connected, U-Boot has to let kernel know via
device-tree. Since modules can be connected in different order and
some modules can be connected multiple times (up to three 8-port
switch modules can be connected), using dtb overlays would result in
too files.
I therefore chose to put all the possible connected devices in one dts
and disable them. If U-Boot finds these modules, it fixes the device
tree accrodginly, by enabling some nodes (setting status to "okay") and
by setting some addresses and references.
For example there are 6 switch nodes - three for 8-port switch module
and three for 4-port switch module. This is because another switch
(either 8-port or 4-port) can be connected to a 8-port switch, in DSA,
and interface names have to be defined (from lan1 to lan24).
Another way (for defining switch nodes) would have to be either:
- including a file where switch nodes are defined, which would need
#defining lan interface names (and some other things), and #undefing
them after the #include
- defining a macro for switch nodes
- have a separate DTBs for each possible configuration (this would
result in too many DTBs)
- not defining these nodes in device-tree at all, instead creating
them in U-Boot when patching the device-tree (I actually tried this,
but the resulting code in U-Boot was horrible)
Please let me know if doing it this way is acceptable, or if I should
try something different (and if yes, what?).
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: linux-kernel@vger.kernel.org
Cc: Gregory CLEMENT
Cc: linux-arm-ker...@lists.infradead.org
Cc: Andrew Lunn
---
.../arm/marvell/armada-3720-turris-mox.txt| 6 +
MAINTAINERS | 1 +
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../dts/marvell/armada-3720-turris-mox.dts| 838 ++
4 files changed, 846 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
diff --git
a/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
b/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
new file mode 100644
index ..408fc07a9bbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-3720-turris-mox.txt
@@ -0,0 +1,6 @@
+CZ.NIC's Turris Mox SOHO router Device Tree Bindings
+
+
+Required root node property:
+
+compatible: must contain "cznic,turris-mox"
diff --git a/MAINTAINERS b/MAINTAINERS
index f6e60e7f6c11..81b57260b110 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1348,6 +1348,7 @@ ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
W: http://mox.turris.cz
S: Maintained
+F: arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
F: include/mfd/moxtet.h
F: drivers/gpio/gpio-moxtet.c
F: drivers/mfd/moxtet.c
diff --git a/arch/arm64/boot/dts/marvell/Makefile
b/arch/arm64/boot/dts/marvell/Makefile
index 5633676fa9d0..51782b31b441 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
# Mvebu SoC Family
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-turris-mox.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
new file mode 100644
index ..1315c59ecef3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -0,0 +1,838 @@
+// SPDX-License-Identifier: GPL-2.0+ or X11
+/*
+ * Device Tree file for CZ.NIC Turris Mox Board
+ * 2018 by Marek Behun
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "armada-372x.dtsi"
+
+/ {
+ model = "CZ.NIC Turris Mox Board";
+ compatible = "cznic,turris-mox", "marvell,armada3720",
+"marvell,armada3710";
+
+ aliases {
+ spi0 = &spi0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x 0x 0x2000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ red {
+
Re: [PATCH v2 03/12] PCI: aardvark: Add PHY support
Hi, One thing for which I would like to be able to disable comphy is that each consumes about 100mW of power. On Turris Mox we configure the comphys to SGMII1, PCIe and USB3 modes. If there is no USB device plugged, the USB3 phy can be disabled, and save 100mW of power. If the PCIe extension module is not present, the PCIe can too be disabled, and if there is no switch nor SFP module present, so can SGMII1. The other reason is this: if the SGMII phy is set to 1G mode, and then powered on second time in 2.5G mode, will it work? I would like to patch mvneta driver to power on/off the comphy, if the device node is present in device tree. But then the system can request such a change (SGMII to 2500BASE-X or back). Marek On Tue, 18 Dec 2018 14:41:30 +0100 Miquel Raynal wrote: > Hi Marek, > > Marek Behun wrote on Tue, 18 Dec 2018 14:09:20 > +0100: > > > > [2] > > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/marvell/comphy/phy-comphy-3700.c > > > > > > > Yes, I used mainline atf (it did not work out of the box with 18.09 > > atf-marvell of course). But there is no _power_off function for > > SGMII, nor a digital_reset function like in cp110 implementation. > > Indeed, but why would you need one? Just use the helpers from the core > and if there is no implementation, nothing should happen and the > helper should exit without error. Just call > phy_set_mode()/phy_power_on() an you should be good. > > > Thanks, > Miquèl
Re: [PATCH v1 1/3] mailbox: Add support for Armada 37xx rWTM mailbox
I forgot to git add the header file containing definitions of
structures for messages :(. Will send in the next version.
On Mon, 17 Dec 2018 16:37:04 +0100
Marek Behún wrote:
> This adds support for the mailbox via which the kernel can communicate
> with the firmware running on the secure processor of the Armada 37xx
> SOC.
>
> The rWTM secure processor has access to internal eFuses and
> cryptographic circuits, such as the Entropy Bit Generator to generate
> true random numbers.
>
> Signed-off-by: Marek Behún
> ---
> drivers/mailbox/Kconfig| 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/armada-37xx-rwtm-mailbox.c | 227
> + 3 files changed, 239 insertions(+)
> create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 3eeb12e93e98..939927290ac6 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -41,6 +41,16 @@ config PL320_MBOX
> Management Engine, primarily for cpufreq. Say Y here if
> you want to use the PL320 IPCM support.
>
> +config ARMADA_37XX_RWTM_MBOX
> + tristate "Armada 37xx rWTM BIU Mailbox"
> + depends on ARCH_MVEBU || COMPILE_TEST
> + depends on OF
> + help
> + Mailbox implementation for communication with the the
> firmware
> + running on the Cortex-M3 rWTM secure processor of the
> Armada 37xx
> + SOC. Say Y here if you are building for such a device (for
> example
> + the Turris Mox router).
> +
> config OMAP2PLUS_MBOX
> tristate "OMAP2+ Mailbox framework support"
> depends on ARCH_OMAP2PLUS
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c818b5d011ae..792894db6b43 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o
>
> obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
>
> +obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o +
> obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
>
> obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
> b/drivers/mailbox/armada-37xx-rwtm-mailbox.c new file mode 100644
> index ..b8b3e8cd49f0
> --- /dev/null
> +++ b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rWTM BIU Mailbox driver for Armada 37xx
> + *
> + * Author: Marek Behun
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "armada-37xx-rwtm-mailbox"
> +
> +/* relative to rWTM BIU Mailbox Registers */
> +#define RWTM_MBOX_PARAM(i) (0x0 + ((i) << 2))
> +#define RWTM_MBOX_COMMAND0x40
> +#define RWTM_MBOX_RETURN_STATUS 0x80
> +#define RWTM_MBOX_STATUS(i) (0x84 + ((i) << 2))
> +#define RWTM_MBOX_FIFO_STATUS0xc4
> +#define FIFO_STS_RDY 0x100
> +#define FIFO_STS_CNTR_MASK 0x7
> +#define FIFO_STS_CNTR_MAX4
> +
> +#define RWTM_HOST_INT_RESET 0xc8
> +#define RWTM_HOST_INT_MASK 0xcc
> +#define SP_CMD_COMPLETE BIT(0)
> +#define SP_CMD_QUEUE_FULL_ACCESS BIT(17)
> +#define SP_CMD_QUEUE_FULLBIT(18)
> +
> +struct a37xx_mbox {
> + struct device *dev;
> + struct mbox_controller controller;
> + void __iomem *base;
> + int irq;
> +};
> +
> +static void a37xx_mbox_receive(struct mbox_chan *chan)
> +{
> + struct a37xx_mbox *mbox = chan->con_priv;
> + struct armada_37xx_rwtm_rx_msg rx_msg;
> + int i;
> +
> + rx_msg.retval = readl(mbox->base + RWTM_MBOX_RETURN_STATUS);
> + for (i = 0; i < 16; ++i)
> + rx_msg.status[i] = readl(mbox->base +
> RWTM_MBOX_STATUS(i)); +
> + mbox_chan_received_data(chan, &rx_msg);
> +}
> +
> +static irqreturn_t a37xx_mbox_irq_handler(int irq, void *data)
> +{
> + struct mbox_chan *chan = data;
> + struct a37xx_mbox *mbox = chan->con_priv;
> + u32 reg;
> +
> + reg = readl(mbox->base + RWTM_HOST_INT_RESET);
> +
> + if (reg & SP_CMD_COMPLETE)
> + a37xx_mbox_receive(chan);
> +
> + if (reg & (SP_CMD_QUEUE_FULL_ACCESS | SP_CMD_QUEUE_FULL))
> + dev_err(mbox->dev, "Secure processor command queue
> full\n"); +
> + writel(reg, mbox->base + RWTM_HOST_INT_RESET);
> + if (reg)
> +
[PATCH v1 1/3] mailbox: Add support for Armada 37xx rWTM mailbox
This adds support for the mailbox via which the kernel can communicate
with the firmware running on the secure processor of the Armada 37xx
SOC.
The rWTM secure processor has access to internal eFuses and
cryptographic circuits, such as the Entropy Bit Generator to generate
true random numbers.
Signed-off-by: Marek Behún
---
drivers/mailbox/Kconfig| 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 227 +
3 files changed, 239 insertions(+)
create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..939927290ac6 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -41,6 +41,16 @@ config PL320_MBOX
Management Engine, primarily for cpufreq. Say Y here if you want
to use the PL320 IPCM support.
+config ARMADA_37XX_RWTM_MBOX
+ tristate "Armada 37xx rWTM BIU Mailbox"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ help
+ Mailbox implementation for communication with the the firmware
+ running on the Cortex-M3 rWTM secure processor of the Armada 37xx
+ SOC. Say Y here if you are building for such a device (for example
+ the Turris Mox router).
+
config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..792894db6b43 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
+obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
+
obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
new file mode 100644
index ..b8b3e8cd49f0
--- /dev/null
+++ b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rWTM BIU Mailbox driver for Armada 37xx
+ *
+ * Author: Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"armada-37xx-rwtm-mailbox"
+
+/* relative to rWTM BIU Mailbox Registers */
+#define RWTM_MBOX_PARAM(i) (0x0 + ((i) << 2))
+#define RWTM_MBOX_COMMAND 0x40
+#define RWTM_MBOX_RETURN_STATUS0x80
+#define RWTM_MBOX_STATUS(i)(0x84 + ((i) << 2))
+#define RWTM_MBOX_FIFO_STATUS 0xc4
+#define FIFO_STS_RDY 0x100
+#define FIFO_STS_CNTR_MASK 0x7
+#define FIFO_STS_CNTR_MAX 4
+
+#define RWTM_HOST_INT_RESET0xc8
+#define RWTM_HOST_INT_MASK 0xcc
+#define SP_CMD_COMPLETEBIT(0)
+#define SP_CMD_QUEUE_FULL_ACCESS BIT(17)
+#define SP_CMD_QUEUE_FULL BIT(18)
+
+struct a37xx_mbox {
+ struct device *dev;
+ struct mbox_controller controller;
+ void __iomem *base;
+ int irq;
+};
+
+static void a37xx_mbox_receive(struct mbox_chan *chan)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_rx_msg rx_msg;
+ int i;
+
+ rx_msg.retval = readl(mbox->base + RWTM_MBOX_RETURN_STATUS);
+ for (i = 0; i < 16; ++i)
+ rx_msg.status[i] = readl(mbox->base + RWTM_MBOX_STATUS(i));
+
+ mbox_chan_received_data(chan, &rx_msg);
+}
+
+static irqreturn_t a37xx_mbox_irq_handler(int irq, void *data)
+{
+ struct mbox_chan *chan = data;
+ struct a37xx_mbox *mbox = chan->con_priv;
+ u32 reg;
+
+ reg = readl(mbox->base + RWTM_HOST_INT_RESET);
+
+ if (reg & SP_CMD_COMPLETE)
+ a37xx_mbox_receive(chan);
+
+ if (reg & (SP_CMD_QUEUE_FULL_ACCESS | SP_CMD_QUEUE_FULL))
+ dev_err(mbox->dev, "Secure processor command queue full\n");
+
+ writel(reg, mbox->base + RWTM_HOST_INT_RESET);
+ if (reg)
+ mbox_chan_txdone(chan, 0);
+
+ return reg ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int a37xx_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_tx_msg *msg = data;
+ int i;
+ u32 reg;
+
+ if (!data)
+ return -EINVAL;
+
+ reg = readl(mbox->base + RWTM_MBOX_FIFO_STATUS);
+ if (!(reg & FIFO_STS_RDY)) {
+ dev_err(mbox->dev, "Secure processor not ready\n");
+ return -EAGAIN;
+ }
+
+ if ((reg & FIFO_STS_CNTR_MASK) >= FIFO_STS_CNTR_MAX) {
+ dev_err(mbox->dev, "Secure processor command queue full\n&
[PATCH v1 2/3] dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding
This adds device tree binding documentation for the rWTM BIU mailbox
driver on the Armada 37xx SOC (EspressoBin, Turris Mox).
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../mailbox/armada-37xx-rwtm-mailbox.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
new file mode 100644
index ..2d182d61eb3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
@@ -0,0 +1,16 @@
+* rWTM BIU Mailbox driver for Armada 37xx
+
+Required properties:
+- compatible : must be "marvell,armada-37xx-rwtm-mailbox"
+- reg :physical base address of the mailbox and length of memory mapped
+ region
+- interrupts: the IRQ line for the mailbox
+- #mbox-cells: must be 1
+
+Example:
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-37xx-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
--
2.18.1
[PATCH v1 3/3] arm64: dts: marvell: armada-37xx: add mailbox node
This adds the rWTM BIU mailbox node for communication with the secure
processor.
Signed-off-by: Marek Behún
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 4472bcd8f9fb..c4c578f7d5e1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -334,6 +334,13 @@
clocks = <&nb_periph_clk 15>;
};
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-37xx-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
sdhci1: sdhci@d {
compatible = "marvell,armada-3700-sdhci",
"marvell,sdhci-xenon";
--
2.18.1
[PATCH v2 bus+gpio 1/4] bus: Add support for Moxtet bus
On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a 4-port switch module, an 8-port switch module, and a 4-port
USB3 module.
For example:
[CPU]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these
are connected via SPI to the CPU board.
Via SPI we are able to discover which modules are connected, in which
order, and we can also read some information about the modules or
configure them.
>From each module 8 bits can be read (of which low 4 bits identify the
module) and 8 bits can be written.
For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.
This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them.
The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.
Signed-off-by: Marek Behún
---
MAINTAINERS| 7 +
drivers/bus/Kconfig| 10 +
drivers/bus/Makefile | 1 +
drivers/bus/moxtet.c | 533 +
include/linux/moxtet.h | 109 +
5 files changed, 660 insertions(+)
create mode 100644 drivers/bus/moxtet.c
create mode 100644 include/linux/moxtet.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c0f771b859e..ccc745d1b430 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1472,6 +1472,13 @@ F: drivers/clocksource/timer-prima2.c
F: drivers/clocksource/timer-atlas7.c
N: [^a-z]sirf
+ARM/CZ.NIC TURRIS MOX SUPPORT
+M: Marek Behun
+W: http://mox.turris.cz
+S: Maintained
+F: include/linux/moxtet.h
+F: drivers/bus/moxtet.c
+
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112ccc29..6b331061d34b 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -29,6 +29,16 @@ config BRCMSTB_GISB_ARB
arbiter. This driver provides timeout and target abort error handling
and internal bus master decoding.
+config MOXTET
+ tristate "CZ.NIC Turris Mox module configuration bus"
+ depends on SPI_MASTER && OF
+ help
+ Say yes here to add support for the module configuration bus found
+ on CZ.NIC's Turris Mox. This is needed for the ability to discover
+ the order in which the modules are connected and to get/set some of
+ their settings. For example the GPIOs on Mox SFP module are
+ configured through this bus.
+
config HISILICON_LPC
bool "Support for ISA I/O space on HiSilicon Hip06/7"
depends on ARM64 && (ARCH_HISI || COMPILE_TEST)
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ca300b1914ce..16b43d3468c6 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_HISILICON_LPC)+= hisi_lpc.o
obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o
+obj-$(CONFIG_MOXTET) += moxtet.o
# DPAA2 fsl-mc bus
obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c
new file mode 100644
index ..19b9d12154d4
--- /dev/null
+++ b/drivers/bus/moxtet.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox module configuration bus driver
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static ssize_t
+module_id_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ struct moxtet_device *mdev = to_moxtet_device(dev);
+
+ return sprintf(buf, "0x%x\n", mdev->id);
+}
+static DEVICE_ATTR_RO(module_id);
+
+static ssize_t
+module_name_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ struct moxtet_device *mdev = to_moxtet_device(dev);
+
+ return sprintf(buf, "%s\n", turris_mox_module_name(mdev->id));
+}
+static DEVICE_ATTR_RO(module_name);
+
+static ssize_t
+input_value_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ int ret;
+
+ ret = moxtet_device_read(dev);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", ret);
+}
+static DEVICE_ATTR_RO(input_value);
+
+static ssize_t
+output_value_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ int ret;
+
+ ret = moxtet_device_written(dev);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", ret);
+}
+
+static ssize_t
+output_value_store(struct device *dev, struct device_attribute *a,
+ const char *buf, size_t cou
[PATCH v2 bus+gpio 4/4] dt-bindings: gpio: Document GPIOs via Moxtet bus
This patch adds documentation of the device tree bindings for GPIOs
on the devices connected via Moxtet bus.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/gpio/gpio-moxtet.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
new file mode 100644
index ..7e9b5770585d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
@@ -0,0 +1,18 @@
+Turris Mox Moxtet GPIO expander via Moxtet bus
+
+Required properties:
+ - compatible : Should be "cznic,moxtet-gpio".
+ - gpio-controller : Marks the device node as a GPIO controller.
+ - #gpio-cells : Should be two. For consumer use see gpio.txt.
+
+Other properties are required for a Moxtet bus device, please refer to
+Documentation/devicetree/bindings/bus/moxtet.txt.
+
+Example:
+
+ moxtet_sfp: moxtet-sfp@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
--
2.18.1
[PATCH v2 bus+gpio 2/4] dt-bindings: bus: Document moxtet bus binding
This adds device tree binding documentation for the Moxtet bus, a bus
via which the different modules connected to the Turris Mox router can
be configured.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/bus/moxtet.txt| 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt
diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt
b/Documentation/devicetree/bindings/bus/moxtet.txt
new file mode 100644
index ..19a1bab61e8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/moxtet.txt
@@ -0,0 +1,34 @@
+Turris Mox module configuration bus (over SPI)
+
+Required properties:
+ - compatible : Should be "cznic,moxtet".
+ - #address-cells : Has to be 1
+ - #size-cells : Has to be 0
+For other required and optional properties of SPI slave nodes please refer to
+../spi/spi-bus.txt.
+
+Required properties of subnodes:
+ - reg : Should be position on the Moxtet bus
+
+The driver finds the devices connected to the bus by itself, but it may be
+needed to reference some of them from other parts of the device tree. In that
+case the devices can be defined as subnodes of the moxtet node.
+
+Example:
+
+ moxtet@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cznic,moxtet";
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ spi-cpol;
+ spi-cpha;
+
+ moxtet_sfp: moxtet-sfp@0 {
+ compatible = "cznic,moxtet-sfp";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
+ };
--
2.18.1
[PATCH v2 bus+gpio 3/4] drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one
device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
Signed-off-by: Marek Behún
---
MAINTAINERS| 1 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-moxtet.c | 178 +
4 files changed, 189 insertions(+)
create mode 100644 drivers/gpio/gpio-moxtet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ccc745d1b430..b8c04b98b92f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1478,6 +1478,7 @@ W:http://mox.turris.cz
S: Maintained
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
+F: drivers/gpio/gpio-moxtet.c
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 833a1b51c948..6e753ce10972 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -334,6 +334,15 @@ config GPIO_MOCKUP
tools/testing/selftests/gpio/gpio-mockup.sh. Reference the usage in
it.
+config GPIO_MOXTET
+ tristate "Turris Mox Moxtet bus GPIO expander"
+ depends on MOXTET
+ help
+ Say yes here if you are building for the Turris Mox router.
+ This is the driver needed for configuring the GPIOs via the Moxtet
+ bus. For example the Mox module with SFP cage needs this driver
+ so that phylink can use corresponding GPIOs.
+
config GPIO_MPC5200
def_bool y
depends on PPC_MPC52xx
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 671c4477c951..044435ac45e2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
+obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxtet.c b/drivers/gpio/gpio-moxtet.c
new file mode 100644
index ..0b0af8651443
--- /dev/null
+++ b/drivers/gpio/gpio-moxtet.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox Moxtet GPIO expander
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+
+#define MOXTET_GPIO_NGPIOS 12
+#define MOXTET_GPIO_INPUTS 4
+
+struct moxtet_gpio_desc {
+ u16 in_mask;
+ u16 out_mask;
+};
+
+static const struct moxtet_gpio_desc descs[] = {
+ [TURRIS_MOX_MODULE_SFP] = {
+ .in_mask = 0x7,
+ .out_mask = 0x30,
+ },
+};
+
+struct moxtet_gpio_chip {
+ struct device *dev;
+ struct gpio_chipgpio_chip;
+ const struct moxtet_gpio_desc *desc;
+};
+
+static int moxtet_gpio_get_value(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int ret;
+
+ if (chip->desc->in_mask & BIT(offset)) {
+ ret = moxtet_device_read(chip->dev);
+ } else if (chip->desc->out_mask & BIT(offset)) {
+ ret = moxtet_device_written(chip->dev);
+ if (ret >= 0)
+ ret <<= MOXTET_GPIO_INPUTS;
+ } else {
+ return -EINVAL;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ return (ret & BIT(offset)) ? 1 : 0;
+}
+
+static void moxtet_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
+ int val)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int state;
+
+ state = moxtet_device_written(chip->dev);
+ if (state < 0)
+ return;
+
+ offset -= MOXTET_GPIO_INPUTS;
+
+ if (val)
+ state |= BIT(offset);
+ else
+ state &= ~BIT(offset);
+
+ moxtet_device_write(chip->dev, state);
+}
+
+static int moxtet_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ if (chip->desc->in_mask & BIT(offset))
+ return 1;
+ else if (chip->desc->out_mask & BIT(offset))
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static int moxtet_gpio_direction_input(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ if (chip->desc->in_mask & BIT(offset))
+ return 0;
+ else if (chip->desc->out_mask & BIT(offset))
+ return -ENOTSUPP;
+ else
+ return -EINVAL;
+}
+
+static int moxtet_gpio_di
[PATCH v3 bus+gpio 5/5] dt-bindings: gpio: Document GPIOs via Moxtet bus
This patch adds documentation of the device tree bindings for GPIOs
on the devices connected via Moxtet bus.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/gpio/gpio-moxtet.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
new file mode 100644
index ..410759de9f09
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
@@ -0,0 +1,18 @@
+Turris Mox Moxtet GPIO expander via Moxtet bus
+
+Required properties:
+ - compatible : Should be "cznic,moxtet-gpio".
+ - gpio-controller : Marks the device node as a GPIO controller.
+ - #gpio-cells : Should be two. For consumer use see gpio.txt.
+
+Other properties are required for a Moxtet bus device, please refer to
+Documentation/devicetree/bindings/bus/moxtet.txt.
+
+Example:
+
+ moxtet_sfp: gpio@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
--
2.19.2
[PATCH v3 bus+gpio 1/5] bus: Add support for Moxtet bus
On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a 4-port switch module, an 8-port switch module, and a 4-port
USB3 module.
For example:
[CPU]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these
are connected via SPI to the CPU board.
Via SPI we are able to discover which modules are connected, in which
order, and we can also read some information about the modules or
configure them.
>From each module 8 bits can be read (of which low 4 bits identify the
module) and 8 bits can be written.
For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.
This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them.
The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.
Signed-off-by: Marek Behún
Acked-by: Linus Walleij
---
MAINTAINERS| 7 +
drivers/bus/Kconfig| 10 +
drivers/bus/Makefile | 1 +
drivers/bus/moxtet.c | 533 +
include/linux/moxtet.h | 109 +
5 files changed, 660 insertions(+)
create mode 100644 drivers/bus/moxtet.c
create mode 100644 include/linux/moxtet.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1e1351bc366d..f6aa13dbb0b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1498,6 +1498,13 @@ F: drivers/clocksource/timer-atlas7.c
N: [^a-z]sirf
X: drivers/gnss
+ARM/CZ.NIC TURRIS MOX SUPPORT
+M: Marek Behun
+W: http://mox.turris.cz
+S: Maintained
+F: include/linux/moxtet.h
+F: drivers/bus/moxtet.c
+
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112ccc29..6b331061d34b 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -29,6 +29,16 @@ config BRCMSTB_GISB_ARB
arbiter. This driver provides timeout and target abort error handling
and internal bus master decoding.
+config MOXTET
+ tristate "CZ.NIC Turris Mox module configuration bus"
+ depends on SPI_MASTER && OF
+ help
+ Say yes here to add support for the module configuration bus found
+ on CZ.NIC's Turris Mox. This is needed for the ability to discover
+ the order in which the modules are connected and to get/set some of
+ their settings. For example the GPIOs on Mox SFP module are
+ configured through this bus.
+
config HISILICON_LPC
bool "Support for ISA I/O space on HiSilicon Hip06/7"
depends on ARM64 && (ARCH_HISI || COMPILE_TEST)
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ca300b1914ce..16b43d3468c6 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_HISILICON_LPC)+= hisi_lpc.o
obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o
+obj-$(CONFIG_MOXTET) += moxtet.o
# DPAA2 fsl-mc bus
obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c
new file mode 100644
index ..19b9d12154d4
--- /dev/null
+++ b/drivers/bus/moxtet.c
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox module configuration bus driver
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static ssize_t
+module_id_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ struct moxtet_device *mdev = to_moxtet_device(dev);
+
+ return sprintf(buf, "0x%x\n", mdev->id);
+}
+static DEVICE_ATTR_RO(module_id);
+
+static ssize_t
+module_name_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ struct moxtet_device *mdev = to_moxtet_device(dev);
+
+ return sprintf(buf, "%s\n", turris_mox_module_name(mdev->id));
+}
+static DEVICE_ATTR_RO(module_name);
+
+static ssize_t
+input_value_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ int ret;
+
+ ret = moxtet_device_read(dev);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", ret);
+}
+static DEVICE_ATTR_RO(input_value);
+
+static ssize_t
+output_value_show(struct device *dev, struct device_attribute *a, char *buf)
+{
+ int ret;
+
+ ret = moxtet_device_written(dev);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%x\n", ret);
+}
+
+static ssize_t
+output_value_store(struct device *dev, struct device_attribute *a,
+ const char *buf, size_
[PATCH v3 bus+gpio 3/5] bus: moxtet: Add sysfs documentation
Add sysfs ABI documentation for the attribute files module_id, module_name, input_value and output_value of Moxtet devices. Signed-off-by: Marek Behún --- .../ABI/testing/sysfs-bus-moxtet-devices | 25 +++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-moxtet-devices diff --git a/Documentation/ABI/testing/sysfs-bus-moxtet-devices b/Documentation/ABI/testing/sysfs-bus-moxtet-devices new file mode 100644 index ..80bae358a90c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-moxtet-devices @@ -0,0 +1,25 @@ +What: /sys/bus/moxtet/devices/moxtet-./module_id +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Moxtet module ID. Format: %x + +What: /sys/bus/moxtet/devices/moxtet-./module_name +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Moxtet module name. Format: string + +What: /sys/bus/moxtet/devices/moxtet-./input_value +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Read input value from module at this Moxtet address. + Format: %x + +What: /sys/bus/moxtet/devices/moxtet-./output_value +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (RW) Read last written value or write value to the module on + this Moxtet address. Format: %x -- 2.19.2
[PATCH v3 bus+gpio 0/5] Add Moxtet bus and GPIO over Moxtet bus
Hello, this is the third version of my patches to support the Moxtet bus and GPIOs over it. Moxtet is a Turris Mox specific tiny bus over SPI. Patches are rebased to current linux-gpio (branch devel and/or for-next). Changes since last version: - addressed the issues in device tree documentation pointed by Rob Herring - cosmetic changes suggested by Linus Walleij - added sysfs ABI documentation for /sys/bus/moxtet/devices attribute files as suggested by Linus Walleij Marek Marek Behún (5): bus: Add support for Moxtet bus dt-bindings: bus: Document moxtet bus binding bus: moxtet: Add sysfs documentation drivers: gpio: Add support for GPIOs over Moxtet bus dt-bindings: gpio: Document GPIOs via Moxtet bus .../ABI/testing/sysfs-bus-moxtet-devices | 25 + .../devicetree/bindings/bus/moxtet.txt| 36 ++ .../devicetree/bindings/gpio/gpio-moxtet.txt | 18 + MAINTAINERS | 8 + drivers/bus/Kconfig | 10 + drivers/bus/Makefile | 1 + drivers/bus/moxtet.c | 533 ++ drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-moxtet.c| 179 ++ include/linux/moxtet.h| 109 11 files changed, 929 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-moxtet-devices create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt create mode 100644 drivers/bus/moxtet.c create mode 100644 drivers/gpio/gpio-moxtet.c create mode 100644 include/linux/moxtet.h -- 2.19.2
[PATCH v3 bus+gpio 2/5] dt-bindings: bus: Document moxtet bus binding
This adds device tree binding documentation for the Moxtet bus, a bus
via which the different modules connected to the Turris Mox router can
be configured.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/bus/moxtet.txt| 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt
diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt
b/Documentation/devicetree/bindings/bus/moxtet.txt
new file mode 100644
index ..2bb998cbd3ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/moxtet.txt
@@ -0,0 +1,36 @@
+Turris Mox module configuration bus (over SPI)
+
+Required properties:
+ - compatible : Should be "cznic,moxtet".
+ - #address-cells : Has to be 1
+ - #size-cells : Has to be 0
+ - spi-cpol: Required inverted clock polarity
+ - spi-cpha: Required shifted clock phase
+For other required and optional properties of SPI slave nodes please refer to
+../spi/spi-bus.txt.
+
+Required properties of subnodes:
+ - reg : Should be position on the Moxtet bus
+
+The driver finds the devices connected to the bus by itself, but it may be
+needed to reference some of them from other parts of the device tree. In that
+case the devices can be defined as subnodes of the moxtet node.
+
+Example:
+
+ moxtet@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "cznic,moxtet";
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ spi-cpol;
+ spi-cpha;
+
+ moxtet_sfp: gpio@0 {
+ compatible = "cznic,moxtet-sfp";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
+ };
--
2.19.2
[PATCH v3 bus+gpio 4/5] drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one
device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
Signed-off-by: Marek Behún
Reviewed-by: Linus Walleij
---
MAINTAINERS| 1 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-moxtet.c | 179 +
4 files changed, 190 insertions(+)
create mode 100644 drivers/gpio/gpio-moxtet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f6aa13dbb0b8..5a445153377a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,6 +1504,7 @@ W:http://mox.turris.cz
S: Maintained
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
+F: drivers/gpio/gpio-moxtet.c
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 3f50526a771f..4f567a2502f1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1424,6 +1424,15 @@ config GPIO_XRA1403
help
GPIO driver for EXAR XRA1403 16-bit SPI-based GPIO expander.
+config GPIO_MOXTET
+ tristate "Turris Mox Moxtet bus GPIO expander"
+ depends on MOXTET
+ help
+ Say yes here if you are building for the Turris Mox router.
+ This is the driver needed for configuring the GPIOs via the Moxtet
+ bus. For example the Mox module with SFP cage needs this driver
+ so that phylink can use corresponding GPIOs.
+
endmenu
menu "USB GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 54d55274b93a..8f20025daf50 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
+obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxtet.c b/drivers/gpio/gpio-moxtet.c
new file mode 100644
index ..2fdd6cdf0db4
--- /dev/null
+++ b/drivers/gpio/gpio-moxtet.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox Moxtet GPIO expander
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+
+#define MOXTET_GPIO_NGPIOS 12
+#define MOXTET_GPIO_INPUTS 4
+
+struct moxtet_gpio_desc {
+ u16 in_mask;
+ u16 out_mask;
+};
+
+static const struct moxtet_gpio_desc descs[] = {
+ [TURRIS_MOX_MODULE_SFP] = {
+ .in_mask = GENMASK(2, 0),
+ .out_mask = GENMASK(5, 4),
+ },
+};
+
+struct moxtet_gpio_chip {
+ struct device *dev;
+ struct gpio_chipgpio_chip;
+ const struct moxtet_gpio_desc *desc;
+};
+
+static int moxtet_gpio_get_value(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int ret;
+
+ if (chip->desc->in_mask & BIT(offset)) {
+ ret = moxtet_device_read(chip->dev);
+ } else if (chip->desc->out_mask & BIT(offset)) {
+ ret = moxtet_device_written(chip->dev);
+ if (ret >= 0)
+ ret <<= MOXTET_GPIO_INPUTS;
+ } else {
+ return -EINVAL;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ return !!(ret & BIT(offset));
+}
+
+static void moxtet_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
+ int val)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int state;
+
+ state = moxtet_device_written(chip->dev);
+ if (state < 0)
+ return;
+
+ offset -= MOXTET_GPIO_INPUTS;
+
+ if (val)
+ state |= BIT(offset);
+ else
+ state &= ~BIT(offset);
+
+ moxtet_device_write(chip->dev, state);
+}
+
+static int moxtet_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ /* All lines are hard wired to be either input or output, not both. */
+ if (chip->desc->in_mask & BIT(offset))
+ return 1;
+ else if (chip->desc->out_mask & BIT(offset))
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static int moxtet_gpio_direction_input(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ if (chip->desc->in_mask & BIT(offset))
+ return 0;
+ else if (chip->desc->out_mask & BIT(offset))
+ return -ENOTSU
[PATCH v2 mailbox 3/3] arm64: dts: marvell: armada-37xx: add mailbox node
This adds the rWTM BIU mailbox node for communication with the secure
processor.
Signed-off-by: Marek Behún
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e05594ea15fb..ecbc293dc8f1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -344,6 +344,13 @@
clocks = <&nb_periph_clk 15>;
};
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
sdhci1: sdhci@d {
compatible = "marvell,armada-3700-sdhci",
"marvell,sdhci-xenon";
--
2.19.2
[PATCH v2 mailbox 1/3] mailbox: Add support for Armada 37xx rWTM mailbox
This adds support for the mailbox via which the kernel can communicate
with the firmware running on the secure processor of the Armada 37xx
SOC.
The rWTM secure processor has access to internal eFuses and
cryptographic circuits, such as the Entropy Bit Generator to generate
true random numbers.
Signed-off-by: Marek Behún
---
drivers/mailbox/Kconfig| 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 227 +
include/linux/armada-37xx-rwtm-mailbox.h | 23 +++
4 files changed, 262 insertions(+)
create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c
create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..939927290ac6 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -41,6 +41,16 @@ config PL320_MBOX
Management Engine, primarily for cpufreq. Say Y here if you want
to use the PL320 IPCM support.
+config ARMADA_37XX_RWTM_MBOX
+ tristate "Armada 37xx rWTM BIU Mailbox"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ help
+ Mailbox implementation for communication with the the firmware
+ running on the Cortex-M3 rWTM secure processor of the Armada 37xx
+ SOC. Say Y here if you are building for such a device (for example
+ the Turris Mox router).
+
config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..792894db6b43 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
+obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
+
obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
new file mode 100644
index ..af8b002e4732
--- /dev/null
+++ b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rWTM BIU Mailbox driver for Armada 37xx
+ *
+ * Author: Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"armada-37xx-rwtm-mailbox"
+
+/* relative to rWTM BIU Mailbox Registers */
+#define RWTM_MBOX_PARAM(i) (0x0 + ((i) << 2))
+#define RWTM_MBOX_COMMAND 0x40
+#define RWTM_MBOX_RETURN_STATUS0x80
+#define RWTM_MBOX_STATUS(i)(0x84 + ((i) << 2))
+#define RWTM_MBOX_FIFO_STATUS 0xc4
+#define FIFO_STS_RDY 0x100
+#define FIFO_STS_CNTR_MASK 0x7
+#define FIFO_STS_CNTR_MAX 4
+
+#define RWTM_HOST_INT_RESET0xc8
+#define RWTM_HOST_INT_MASK 0xcc
+#define SP_CMD_COMPLETEBIT(0)
+#define SP_CMD_QUEUE_FULL_ACCESS BIT(17)
+#define SP_CMD_QUEUE_FULL BIT(18)
+
+struct a37xx_mbox {
+ struct device *dev;
+ struct mbox_controller controller;
+ void __iomem *base;
+ int irq;
+};
+
+static void a37xx_mbox_receive(struct mbox_chan *chan)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_rx_msg rx_msg;
+ int i;
+
+ rx_msg.retval = readl(mbox->base + RWTM_MBOX_RETURN_STATUS);
+ for (i = 0; i < 16; ++i)
+ rx_msg.status[i] = readl(mbox->base + RWTM_MBOX_STATUS(i));
+
+ mbox_chan_received_data(chan, &rx_msg);
+}
+
+static irqreturn_t a37xx_mbox_irq_handler(int irq, void *data)
+{
+ struct mbox_chan *chan = data;
+ struct a37xx_mbox *mbox = chan->con_priv;
+ u32 reg;
+
+ reg = readl(mbox->base + RWTM_HOST_INT_RESET);
+
+ if (reg & SP_CMD_COMPLETE)
+ a37xx_mbox_receive(chan);
+
+ if (reg & (SP_CMD_QUEUE_FULL_ACCESS | SP_CMD_QUEUE_FULL))
+ dev_err(mbox->dev, "Secure processor command queue full\n");
+
+ writel(reg, mbox->base + RWTM_HOST_INT_RESET);
+ if (reg)
+ mbox_chan_txdone(chan, 0);
+
+ return reg ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int a37xx_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_tx_msg *msg = data;
+ int i;
+ u32 reg;
+
+ if (!data)
+ return -EINVAL;
+
+ reg = readl(mbox->base + RWTM_MBOX_FIFO_STATUS);
+ if (!(reg & FIFO_STS_RDY)) {
+ dev_err(mbox->dev, "Secure processor not ready\n");
+ return -EAGAIN;
+ }
+
+ if ((reg & FI
[PATCH v2 mailbox 0/3] Armada 37xx mailbox support
Hi, this is the second version of patches I sent in December, rebased onto current linux/master. Changes since previous version: - compatible string changed not to use wildcards, as requested by Rob Herring Marek Marek Behún (3): mailbox: Add support for Armada 37xx rWTM mailbox dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding arm64: dts: marvell: armada-37xx: add mailbox node .../mailbox/armada-37xx-rwtm-mailbox.txt | 16 ++ arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 + drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/armada-37xx-rwtm-mailbox.c| 227 ++ include/linux/armada-37xx-rwtm-mailbox.h | 23 ++ 6 files changed, 285 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h -- 2.19.2
[PATCH v2 mailbox 2/3] dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding
This adds device tree binding documentation for the rWTM BIU mailbox
driver on the Armada 37xx SOC (EspressoBin, Turris Mox).
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../mailbox/armada-37xx-rwtm-mailbox.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
new file mode 100644
index ..282ab81a4ea6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/armada-37xx-rwtm-mailbox.txt
@@ -0,0 +1,16 @@
+* rWTM BIU Mailbox driver for Armada 37xx
+
+Required properties:
+- compatible: must be "marvell,armada-3700-rwtm-mailbox"
+- reg: physical base address of the mailbox and length of memory mapped
+ region
+- interrupts: the IRQ line for the mailbox
+- #mbox-cells: must be 1
+
+Example:
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
--
2.19.2
[PATCH v4.1 armsoc/drivers/bus+gpio 2/5] dt-bindings: bus: Document moxtet bus binding
This adds device tree binding documentation for the Moxtet bus, a bus
via which the different modules connected to the Turris Mox router can
be configured.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/bus/moxtet.txt| 44 +++
MAINTAINERS | 1 +
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt
diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt
b/Documentation/devicetree/bindings/bus/moxtet.txt
new file mode 100644
index ..7be9d00c1767
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/moxtet.txt
@@ -0,0 +1,46 @@
+Turris Mox module status and configuration bus (over SPI)
+
+Required properties:
+ - compatible : Should be "cznic,moxtet"
+ - #address-cells : Has to be 1
+ - #size-cells : Has to be 0
+ - spi-cpol: Required inverted clock polarity
+ - spi-cpha: Required shifted clock phase
+ - interrupts : Must contain reference to the shared interrupt line
+ - interrupt-controller: Required
+ - #interrupt-cells: Has to be 1
+
+For other required and optional properties of SPI slave nodes please refer to
+../spi/spi-bus.txt.
+
+Required properties of subnodes:
+ - reg : Should be position on the Moxtet bus (how many Moxtet
+ modules are between this module and CPU module, so
+ either 0 or a positive integer)
+
+The driver finds the devices connected to the bus by itself, but it may be
+needed to reference some of them from other parts of the device tree. In that
+case the devices can be defined as subnodes of the moxtet node.
+
+Example:
+
+ moxtet@1 {
+ compatible = "cznic,moxtet";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gpiosb>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ moxtet_sfp: gpio@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index d96d36c83bc3..3f461a2d776a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1502,6 +1502,7 @@ ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
W: http://mox.turris.cz
S: Maintained
+F: Documentation/devicetree/bindings/bus/moxtet.txt
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
--
2.19.2
[PATCH v3 mailbox+firmware 4/6] firmware: Add Turris Mox rWTM firmware driver
This adds a driver to communicate with the firmware running on the
secure processor of the Turris Mox router, enabling the kernel to
retrieve true random numbers from the Entropy Bit Generator and to
sign messages with the ECDSA private key burned into each Turris Mox
device when manufacturing.
This also adds support to read other information burned into eFuses:
- serial number
- board version
- MAC addresses
- RAM size
- ECDSA public key (this is not read directly from eFuses, rather it
is computed by the firmware as pair to the burned private key)
The source code of the firmware is open source and can be found at
https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi
Signed-off-by: Marek Behún
---
drivers/firmware/Kconfig | 14 +
drivers/firmware/Makefile | 1 +
drivers/firmware/turris-mox-rwtm.c | 508 +
3 files changed, 523 insertions(+)
create mode 100644 drivers/firmware/turris-mox-rwtm.c
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index f754578414f0..7b665c52e6fd 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -267,6 +267,20 @@ config TI_SCI_PROTOCOL
This protocol library is used by client drivers to use the features
provided by the system controller.
+config TURRIS_MOX_RWTM
+ tristate "Turris Mox rWTM secure firmware driver"
+ depends on HAS_DMA && OF
+ depends on MAILBOX
+ select HW_RANDOM
+ select ARMADA_37XX_RWTM_MBOX
+ help
+ This driver communicates with the firmware on the Cortex-M3 secure
+ processor of the Turris Mox router. Enable if you are building for
+ Turris Mox, and you will be able to read the serial number and
+ other manufacturing data, sign messages with the internal ECDSA-521
+ private key and utilize the Entropy Bit Generator as hardware random
+ number generator.
+
config HAVE_ARM_SMCCC
bool
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 80feb635120f..7300787141f5 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_SCM_64) += qcom_scm-64.o
obj-$(CONFIG_QCOM_SCM_32) += qcom_scm-32.o
CFLAGS_qcom_scm-32.o :=$(call as-instr,.arch armv7-a\n.arch_extension
sec,-DREQUIRES_SEC=1) -march=armv7-a
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
+obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
obj-$(CONFIG_ARM_SCMI_PROTOCOL)+= arm_scmi/
obj-y += broadcom/
diff --git a/drivers/firmware/turris-mox-rwtm.c
b/drivers/firmware/turris-mox-rwtm.c
new file mode 100644
index ..e5d66460f85b
--- /dev/null
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -0,0 +1,508 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox rWTM firmware driver
+ *
+ * Copyright (C) 2019 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"turris-mox-rwtm"
+
+/*
+ * The macros and constants below come from Turris Mox's rWTM firmware code.
+ * This firmware is open source and it's sources can be found at
+ * https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi.
+ */
+
+#define MBOX_STS_SUCCESS (0 << 30)
+#define MBOX_STS_FAIL (1 << 30)
+#define MBOX_STS_BADCMD(2 << 30)
+#define MBOX_STS_ERROR(s) ((s) & (3 << 30))
+#define MBOX_STS_VALUE(s) (((s) >> 10) & 0xf)
+#define MBOX_STS_CMD(s)((s) & 0x3ff)
+
+enum mbox_cmd {
+ MBOX_CMD_GET_RANDOM = 1,
+ MBOX_CMD_BOARD_INFO = 2,
+ MBOX_CMD_ECDSA_PUB_KEY = 3,
+ MBOX_CMD_HASH = 4,
+ MBOX_CMD_SIGN = 5,
+ MBOX_CMD_VERIFY = 6,
+
+ MBOX_CMD_OTP_READ = 7,
+ MBOX_CMD_OTP_WRITE = 8,
+};
+
+struct mox_kobject;
+
+struct mox_rwtm {
+ struct device *dev;
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox;
+ struct mox_kobject *kobj;
+ struct hwrng hwrng;
+
+ struct armada_37xx_rwtm_rx_msg reply;
+
+ void *buf;
+ dma_addr_t buf_phys;
+
+ /*
+* If cmd_done_cb is not null, it is called on rWTM reply event.
+* Otherwise cmd_done completion is completed.
+*/
+ struct mutex busy;
+ struct completion cmd_done;
+ void (*cmd_done_cb)(struct mox_rwtm *rwtm);
+
+ /* board information */
+ int has_board_info;
+ u64 serial_number;
+ int board_version, ram_size;
+ u8 mac_address1[6], mac_address2[6];
+
+ /* public key burned in eFuse */
+ int has_pubkey;
+ u8 pubkey[135];
+
+ /* signature process */
+ struct kernfs_node *do_sign_kn;
+ u32 last_sig[34];
+ int last_sig_result;
+};
+
+struct mox_kobject {
[PATCH v3 mailbox+firmware 5/6] firmware: turris-mox-rwtm: Add sysfs documentation
Add sysfs ABI documentation for the sysfs files created by the turris-mox-rwtm driver. Signed-off-by: Marek Behún --- .../testing/sysfs-firmware-turris-mox-rwtm| 60 +++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm new file mode 100644 index ..ff6cd30f0cf2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm @@ -0,0 +1,60 @@ +What: /sys/firmware/turris-mox-rwtm/board_version +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Board version burned into eFuses of this Turris Mox board. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/do_sign +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (RW) Gate for writing requests for signature with the ECDSA + private key burned into eFuses during the manufacturing process, + and also for reading the resulting signature. + + When requesting for signature, a SHA-512 hash of the message to + be signed should be written in binary form to this file. This + means that a write() operation into this file shall write + exactly 64 bytes, buffers of other size are ignored. + + When the signature is done or the rWTM firmware responded with + an error, this file is notified via poll, and the result can + then be read. On error, the read() operation fails with errno + corresponding with the error. On success, 136 bytes are copied + to the buffer - 68 bytes for the R value and 68 for the S value + of the ECDSA signature, in binary form. These are 2 arrays of 17 + 32-bit words, in big-endian form, most significat word first. + + Format: binary + +What: /sys/firmware/turris-mox-rwtm/mac_address* +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) MAC addresses burned into eFuses of this Turris Mox board. + Format: %pM + +What: /sys/firmware/turris-mox-rwtm/pubkey +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) ECDSA public key (in pubkey hex compressed form) computed + as pair to the ECDSA private key burned into eFuses of this + Turris Mox Board. + Format: string + +What: /sys/firmware/turris-mox-rwtm/ram_size +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) RAM size in MiB of this Turris Mox board as was detected + during manufacturing and burned into eFuses. Can be 512 or 1024. + Format: %i + +What: /sys/firmware/turris-mox-rwtm/serial_number +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Serial number burned into eFuses of this Turris Mox device. + Format: %016X -- 2.19.2
[PATCH v3 mailbox+firmware 0/6] Armada 37xx mailbox + Turris Mox secure firmware support
Hello, this is the third version of my patches to add support for rWTM mailbox of Marvell A3700 compatible devices, this time also with turris-mox-rwtm firmware driver. I would like to ask you guys for reviews, since I didn't get any review for the first patch (adding mailbox support) yet. What's new in v3: - Three more patches, to add support for communicating with the secure firmware on the Turris Mox board. The driver for this firmware needs the mailbox driver to be able to communicate with the secure processor. Changes since v2: - changed the mailbox driver not to fail when sending a message if the firmware reports that secure processor is not ready. The firmware on EspressoBin does not indicate that it is ready in the designated register, even if it answers to commands. Print only a warning if the ready flag is not set in the FIFO_STATUS register. - added Rob's Reviewed-by tag for the mailbox dt-binding patch Marek Marek Behún (6): mailbox: Add support for Armada 37xx rWTM mailbox dt-bindings: mailbox: Document armada-3700-rwtm-mailbox binding arm64: dts: marvell: armada-37xx: add mailbox node firmware: Add Turris Mox rWTM firmware driver firmware: turris-mox-rwtm: Add sysfs documentation dt-bindings: firmware: Document cznic,turris-mox-rwtm binding .../testing/sysfs-firmware-turris-mox-rwtm| 60 +++ .../firmware/cznic,turris-mox-rwtm.txt| 19 + .../marvell,armada-3700-rwtm-mailbox.txt | 16 + arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 + drivers/firmware/Kconfig | 14 + drivers/firmware/Makefile | 1 + drivers/firmware/turris-mox-rwtm.c| 508 ++ drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/armada-37xx-rwtm-mailbox.c| 225 include/linux/armada-37xx-rwtm-mailbox.h | 23 + 11 files changed, 885 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm create mode 100644 Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt create mode 100644 Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt create mode 100644 drivers/firmware/turris-mox-rwtm.c create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h -- 2.19.2
[PATCH v3 mailbox+firmware 6/6] dt-bindings: firmware: Document cznic,turris-mox-rwtm binding
This adds device tree binding documentation for the driver communicating
with the rWTM firmware on Turris Mox.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../firmware/cznic,turris-mox-rwtm.txt| 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
diff --git
a/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
new file mode 100644
index ..338169dea7bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt
@@ -0,0 +1,19 @@
+Turris Mox rWTM firmware driver
+
+Required properties:
+ - compatible : Should be "cznic,turris-mox-rwtm"
+ - mboxes : Must contain a reference to associated mailbox
+
+This device tree node should be used on Turris Mox, or potentially another
A3700
+compatible device running the Mox's rWTM firmware in the secure processor (for
+example it is possible to flash this firmware into EspressoBin).
+
+Example:
+
+ firmware {
+ turris-mox-rwtm {
+ compatible = "cznic,turris-mox-rwtm";
+ mboxes = <&rwtm 0>;
+ status = "okay";
+ };
+ };
--
2.19.2
[PATCH v3 mailbox+firmware 2/6] dt-bindings: mailbox: Document armada-3700-rwtm-mailbox binding
This adds device tree binding documentation for the rWTM BIU mailbox
driver on the Armada 37xx SOC (EspressoBin, Turris Mox).
Signed-off-by: Marek Behún
Reviewed-by: Rob Herring
---
.../mailbox/marvell,armada-3700-rwtm-mailbox.txt | 16
1 file changed, 16 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
new file mode 100644
index ..282ab81a4ea6
--- /dev/null
+++
b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
@@ -0,0 +1,16 @@
+* rWTM BIU Mailbox driver for Armada 37xx
+
+Required properties:
+- compatible: must be "marvell,armada-3700-rwtm-mailbox"
+- reg: physical base address of the mailbox and length of memory mapped
+ region
+- interrupts: the IRQ line for the mailbox
+- #mbox-cells: must be 1
+
+Example:
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
--
2.19.2
[PATCH v3 mailbox+firmware 3/6] arm64: dts: marvell: armada-37xx: add mailbox node
This adds the rWTM BIU mailbox node for communication with the secure
processor.
Signed-off-by: Marek Behún
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 87cc84aae6ac..b2e55576b806 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -419,6 +419,13 @@
clocks = <&nb_periph_clk 15>;
};
+ rwtm: mailbox@b {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
sdhci1: sdhci@d {
compatible = "marvell,armada-3700-sdhci",
"marvell,sdhci-xenon";
--
2.19.2
[PATCH v3 mailbox+firmware 1/6] mailbox: Add support for Armada 37xx rWTM mailbox
This adds support for the mailbox via which the kernel can communicate
with the firmware running on the secure processor of the Armada 37xx
SOC.
The rWTM secure processor has access to internal eFuses and
cryptographic circuits, such as the Entropy Bit Generator to generate
true random numbers.
Signed-off-by: Marek Behún
---
drivers/mailbox/Kconfig| 10 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/armada-37xx-rwtm-mailbox.c | 225 +
include/linux/armada-37xx-rwtm-mailbox.h | 23 +++
4 files changed, 260 insertions(+)
create mode 100644 drivers/mailbox/armada-37xx-rwtm-mailbox.c
create mode 100644 include/linux/armada-37xx-rwtm-mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..939927290ac6 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -41,6 +41,16 @@ config PL320_MBOX
Management Engine, primarily for cpufreq. Say Y here if you want
to use the PL320 IPCM support.
+config ARMADA_37XX_RWTM_MBOX
+ tristate "Armada 37xx rWTM BIU Mailbox"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ help
+ Mailbox implementation for communication with the the firmware
+ running on the Cortex-M3 rWTM secure processor of the Armada 37xx
+ SOC. Say Y here if you are building for such a device (for example
+ the Turris Mox router).
+
config OMAP2PLUS_MBOX
tristate "OMAP2+ Mailbox framework support"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..792894db6b43 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU) += arm_mhu.o
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
+obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
+
obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
diff --git a/drivers/mailbox/armada-37xx-rwtm-mailbox.c
b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
new file mode 100644
index ..97f90e97a83c
--- /dev/null
+++ b/drivers/mailbox/armada-37xx-rwtm-mailbox.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * rWTM BIU Mailbox driver for Armada 37xx
+ *
+ * Author: Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"armada-37xx-rwtm-mailbox"
+
+/* relative to rWTM BIU Mailbox Registers */
+#define RWTM_MBOX_PARAM(i) (0x0 + ((i) << 2))
+#define RWTM_MBOX_COMMAND 0x40
+#define RWTM_MBOX_RETURN_STATUS0x80
+#define RWTM_MBOX_STATUS(i)(0x84 + ((i) << 2))
+#define RWTM_MBOX_FIFO_STATUS 0xc4
+#define FIFO_STS_RDY 0x100
+#define FIFO_STS_CNTR_MASK 0x7
+#define FIFO_STS_CNTR_MAX 4
+
+#define RWTM_HOST_INT_RESET0xc8
+#define RWTM_HOST_INT_MASK 0xcc
+#define SP_CMD_COMPLETEBIT(0)
+#define SP_CMD_QUEUE_FULL_ACCESS BIT(17)
+#define SP_CMD_QUEUE_FULL BIT(18)
+
+struct a37xx_mbox {
+ struct device *dev;
+ struct mbox_controller controller;
+ void __iomem *base;
+ int irq;
+};
+
+static void a37xx_mbox_receive(struct mbox_chan *chan)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_rx_msg rx_msg;
+ int i;
+
+ rx_msg.retval = readl(mbox->base + RWTM_MBOX_RETURN_STATUS);
+ for (i = 0; i < 16; ++i)
+ rx_msg.status[i] = readl(mbox->base + RWTM_MBOX_STATUS(i));
+
+ mbox_chan_received_data(chan, &rx_msg);
+}
+
+static irqreturn_t a37xx_mbox_irq_handler(int irq, void *data)
+{
+ struct mbox_chan *chan = data;
+ struct a37xx_mbox *mbox = chan->con_priv;
+ u32 reg;
+
+ reg = readl(mbox->base + RWTM_HOST_INT_RESET);
+
+ if (reg & SP_CMD_COMPLETE)
+ a37xx_mbox_receive(chan);
+
+ if (reg & (SP_CMD_QUEUE_FULL_ACCESS | SP_CMD_QUEUE_FULL))
+ dev_err(mbox->dev, "Secure processor command queue full\n");
+
+ writel(reg, mbox->base + RWTM_HOST_INT_RESET);
+ if (reg)
+ mbox_chan_txdone(chan, 0);
+
+ return reg ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int a37xx_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct a37xx_mbox *mbox = chan->con_priv;
+ struct armada_37xx_rwtm_tx_msg *msg = data;
+ int i;
+ u32 reg;
+
+ if (!data)
+ return -EINVAL;
+
+ reg = readl(mbox->base + RWTM_MBOX_FIFO_STATUS);
+ if (!(reg & FIFO_STS_RDY))
+ dev_warn(mbox->dev, "Secure processor not ready\n");
+
+ if ((reg & FIFO_STS_CNTR_MASK) >= FIFO_STS_CNTR_MAX) {
+
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, 09 Feb 2021 15:16:45 -0800 nnet wrote: > I've two of these and I've just swapped them (and re-pasted the heat sinks). > > The second one ran under load for awhile and now has frozen as well. > > Under a moderate load `wget -O /dev/null ` @X00Mbits they are fine. > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > They fine with both those workloads @1000_800. > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. Try disabling cpufreq in kernel completely, compile boot image at 1200 MHz. If it continues freezing, then I fear we can't help you with 1200 MHz :( Marek
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, 09 Feb 2021 17:51:53 -0800 nnet wrote: > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > > On Tue, 09 Feb 2021 15:16:45 -0800 > > > nnet wrote: > > > > > > > I've two of these and I've just swapped them (and re-pasted the heat > > > > sinks). > > > > > > > > The second one ran under load for awhile and now has frozen as well. > > > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they > > > > are fine. > > > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > > > > > > > They fine with both those workloads @1000_800. > > > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. > > > > > > Try disabling cpufreq in kernel completely, compile boot image at > > > 1200 MHz. If it continues freezing, then I fear we can't help you with > > > 1200 MHz :( > > > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > > 20 30 60 120 > > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load: > > > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > Setting it back to min 200MHz I get a freeze within a minute: > > > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > Marek > > > > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > Based on the below at boot time might an equivalent of the above need to be > 1225 for 1.2GHz? > > 1200_750 > SVC REV: 5, CPU VDD voltage: 1.225V > > 1000_800 > SVC REV: 5, CPU VDD voltage: 1.108V It may be... But it is possible that the value 1.225 is computed by the code by default. Marek
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wed, 10 Feb 2021 11:08:59 -0800 nnet wrote: > => md d0012604 1; md d0012604 1; md d0012604 1 > d0012604: 2b417501 .uA+ > d0012604: 945b [... > d0012604: So this means that in OTP you have this values: 1200 MHz - 1213 mV 1000 MHz - 1213 mV 800 MHz - 1097 mV 600 MHz - 898 mV
Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management
/o\ How did I manage to miss this? Please wait a few minutes I am just going to do a fast compile and test. Marek
Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management
On Wed, 17 Feb 2021 15:30:38 +
Rui Salvaterra wrote:
> Hardware buffer management has never worked on the Turris Omnia, as the
> required MBus window hadn't been reserved. Fix thusly.
>
> Fixes: 018b88eee1a2 ("ARM: dts: turris-omnia: enable HW buffer management")
>
> Signed-off-by: Rui Salvaterra
Reviewed-by: Marek Behún
Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management
Rui, in the future make the subject prefix [PATCH mvebu-dt] or [PATCH mvebu/dt] so that Gregory knows its for him and for which branch. Marek
Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management
On Wed, 17 Feb 2021 17:22:17 +0100 Andrew Lunn wrote: > On Wed, Feb 17, 2021 at 03:30:38PM +, Rui Salvaterra wrote: > > Hardware buffer management has never worked on the Turris Omnia, as the > > required MBus window hadn't been reserved. Fix thusly. > > Hi Rui > > I don't know all the details for the MBus Windows... > > Can this be set once in armada-385.dtsi ? > > Did you check the other dts files. Do any others have the same > problem? > > Andrew armada-38x.dtsi defines only ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>; for internal-regs. It probably depends on how the mbus driver works. If the mbus driver maps every window defined in ranges, regardless whether they are used, then we do not want to put all windows in .dtsi file. Marek
Re: [PATCH v3 1/2] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips
Hi Pali,
I have rewritten the commit message a little:
The workaround for VSOL V2801F brand based GPON SFP modules added in
commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490
v2.0 workaround") works only for IDs added explicitly to the list.
Since there are rebranded modules where OEM vendors put different
strings into the vendor name field, we cannot base workaround on IDs
only.
Moreover the issue which the above mentioned commit tried to work
around is generic not only to VSOL based modules, but rather to all
GPON modules based on Realtek RTL8672 and RTL9601C chips.
These include at least the following GPON modules:
* V-SOL V2801F
* C-Data FD511GX-RM0
* OPTON GP801R
* BAUDCOM BD-1234-SFM
* CPGOS03-0490 v2.0
* Ubiquiti U-Fiber Instant
* EXOT EGS1
These Realtek chips have broken EEPROM emulator which for N-byte read
operation returns just the first byte of EEPROM data, followed by N-1 zeros.
Introduce a new function, sfp_id_needs_byte_io(), which detects SFP
modules with broken EEPROM emulator based on N-1 zeros and switch to 1
byte EEPROM reading operation.
Function sfp_i2c_read() now always uses single byte reading when it is
required and when function sfp_hwmon_probe() detects single byte access,
it disables registration of hwmon device, because in this case we
cannot reliably and atomically read 2 bytes as is required byt the
standard for retrieving values from diagnostic area.
(These Realtek chips are broken in a way that violates SFP standards for
diagnostic interface. Kernel in this case simply cannot do anything
less of skipping registration of the hwmon interface.)
This patch fixes reading of EEPROM content from SFP modules based on
Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays
broken and cannot be fixed.
Re: [PATCH v3 2/2] net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant
On Mon, 11 Jan 2021 12:39:09 +0100 Pali Rohár wrote: > SFP GPON module Ubiquiti U-Fiber Instant has in its EEPROM stored nonsense > information. It claims that support all transceiver types including 10G > Ethernet which is not truth. So clear all claimed modes and set only one > mode which module supports: 1000baseX_Full. The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information stored in int EEPROM. It claims to support all transceiver types including 10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is the only one supported. > Also this module have set SFF phys_id in its EEPROM. Kernel SFP subsustem > currently does not allow to use SFP modules detected as SFF. Therefore add > and exception for this module so it can be detected as supported. This module has also phys_id set to SFF, and the SFP subsystem currently does not allow to use SFP modules detected as SFFs. Add exception for this module so it can be detected as supported. > This change finally allows to detect and use SFP GPON module Ubiquiti > U-Fiber Instant on Linux system. > > Original EEPROM content is as follows (where XX is serial number): > > 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8?????.?? > 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20UBNT > 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41.??)UF-INSTA > 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36NT 4 ??.6 > 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX.?..UBNT > 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41140123 `??A
Re: [PATCH net-next 0/2] dsa: add MT7530 GPIO support
Qingfang, what modes does the LED support? Does it support blinking on rx/tx? What about link status? I'd like to know because I am still working on patches which add ethernet PHY/switch LEDs, with transparent offloading of netdev trigger. Marek On Mon, 11 Jan 2021 13:44:26 +0800 DENG Qingfang wrote: > MT7530's LED controller can be used as GPIO controller. Add support for > it. > > DENG Qingfang (2): > dt-bindings: net: dsa: add MT7530 GPIO controller binding > drivers: net: dsa: mt7530: MT7530 optional GPIO support > > .../devicetree/bindings/net/dsa/mt7530.txt| 6 ++ > drivers/net/dsa/mt7530.c | 96 +++ > drivers/net/dsa/mt7530.h | 20 > 3 files changed, 122 insertions(+) >
Re: [PATCH] Signed-off-by: giladreti
The Signed-off-by line should be last in the commit message, not first. First line (which becomes e-mail subject) should describe what the commit does (in a short one liner) and where it does it. So for your patch it could be something like bpf: support pointer to mem register spilling in verifier The commit message should be written in present simple tense, not past simple, ie. not "Added support" but "Add support". Also we need your name and surname in From: header and Signed-off-by: tag. So instead of giladreti it should be Gilad Reti if that is your real time. If it is not, please provide your real name. On Mon, 11 Jan 2021 17:31:23 +0200 giladreti wrote: > Added support for pointer to mem register spilling, to allow the verifier > to track pointer to valid memory addresses. Such pointers are returned > for example by a successful call of the bpf_ringbuf_reserve helper. > > This patch was suggested as a solution by Yonghong Song. > --- > kernel/bpf/verifier.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 17270b8404f1..36af69fac591 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -2217,6 +2217,8 @@ static bool is_spillable_regtype(enum bpf_reg_type type) > case PTR_TO_RDWR_BUF: > case PTR_TO_RDWR_BUF_OR_NULL: > case PTR_TO_PERCPU_BTF_ID: > + case PTR_TO_MEM: > + case PTR_TO_MEM_OR_NULL: > return true; > default: > return false;
Re: [PATCH v2 1/3] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips
On Thu, 7 Jan 2021 19:45:49 + Russell King - ARM Linux admin wrote: > I think you're not reading the code very well. It checks for bytes at > offset 1..blocksize-1, blocksize+1..2*blocksize-1, etc are zero. It > does _not_ check that byte 0 or the byte at N*blocksize is zero - these > bytes are skipped. In other words, the first byte of each transfer can > be any value. The other bytes of the _entire_ ID must be zero. Wouldn't it be better, instead of checking if 1..blocksize-1 are zero, to check whether reading byte by byte returns the same as reading 16 bytes whole? Marek
Re: [PATCH 2/4] net: sfp: allow to use also SFP modules which are detected as SFF
On Wed, 30 Dec 2020 18:06:52 +0100 Pali Rohár wrote: > if (!sfp->type->module_supported(&id) && > (memcmp(id.base.vendor_name, "UBNT", 16) || >memcmp(id.base.vendor_pn, "UF-INSTANT ", 16))) I would rather add a quirk member (bitfield) to the sfp structure and do something like this if (!sfp->type->module_supported(&id) && !(sfp->quirks & SFP_QUIRK_BAD_PHYS_ID)) or maybe put this check into the module_supported method. Marek
[PATCH 2/2] treewide: change my e-mail address, fix my name
Change my e-mail address to ka...@kernel.org, and fix my name in non-code parts (add diacritical mark). Signed-off-by: Marek Behún --- Documentation/ABI/testing/debugfs-moxtet | 4 ++-- Documentation/ABI/testing/debugfs-turris-mox-rwtm | 2 +- Documentation/ABI/testing/sysfs-bus-moxtet-devices | 6 +++--- .../ABI/testing/sysfs-class-led-driver-turris-omnia| 2 +- .../ABI/testing/sysfs-firmware-turris-mox-rwtm | 10 +- .../bindings/leds/cznic,turris-omnia-leds.yaml | 2 +- MAINTAINERS| 2 +- arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +- drivers/bus/moxtet.c | 4 ++-- drivers/firmware/turris-mox-rwtm.c | 4 ++-- drivers/gpio/gpio-moxtet.c | 4 ++-- drivers/leds/leds-turris-omnia.c | 4 ++-- drivers/mailbox/armada-37xx-rwtm-mailbox.c | 4 ++-- drivers/watchdog/armada_37xx_wdt.c | 4 ++-- include/dt-bindings/bus/moxtet.h | 2 +- include/linux/armada-37xx-rwtm-mailbox.h | 2 +- include/linux/moxtet.h | 2 +- 17 files changed, 30 insertions(+), 30 deletions(-) diff --git a/Documentation/ABI/testing/debugfs-moxtet b/Documentation/ABI/testing/debugfs-moxtet index 6eee10c3d5a1..637d8587d03d 100644 --- a/Documentation/ABI/testing/debugfs-moxtet +++ b/Documentation/ABI/testing/debugfs-moxtet @@ -1,7 +1,7 @@ What: /sys/kernel/debug/moxtet/input Date: March 2019 KernelVersion: 5.3 -Contact: Marek Behún +Contact: Marek Behún Description: (Read) Read input from the shift registers, in hexadecimal. Returns N+1 bytes, where N is the number of Moxtet connected modules. The first byte is from the CPU board itself. @@ -19,7 +19,7 @@ Description: (Read) Read input from the shift registers, in hexadecimal. What: /sys/kernel/debug/moxtet/output Date: March 2019 KernelVersion: 5.3 -Contact: Marek Behún +Contact: Marek Behún Description: (RW) Read last written value to the shift registers, in hexadecimal, or write values to the shift registers, also in hexadecimal. diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm index 326df1b74707..813987d5de4e 100644 --- a/Documentation/ABI/testing/debugfs-turris-mox-rwtm +++ b/Documentation/ABI/testing/debugfs-turris-mox-rwtm @@ -1,7 +1,7 @@ What: /sys/kernel/debug/turris-mox-rwtm/do_sign Date: Jun 2020 KernelVersion: 5.8 -Contact: Marek Behún +Contact: Marek Behún Description: === === diff --git a/Documentation/ABI/testing/sysfs-bus-moxtet-devices b/Documentation/ABI/testing/sysfs-bus-moxtet-devices index 4a6d61b44f3f..32dccc00d57d 100644 --- a/Documentation/ABI/testing/sysfs-bus-moxtet-devices +++ b/Documentation/ABI/testing/sysfs-bus-moxtet-devices @@ -1,17 +1,17 @@ What: /sys/bus/moxtet/devices/moxtet-./module_description Date: March 2019 KernelVersion: 5.3 -Contact: Marek Behún +Contact: Marek Behún Description: (Read) Moxtet module description. Format: string What: /sys/bus/moxtet/devices/moxtet-./module_id Date: March 2019 KernelVersion: 5.3 -Contact: Marek Behún +Contact: Marek Behún Description: (Read) Moxtet module ID. Format: %x What: /sys/bus/moxtet/devices/moxtet-./module_name Date: March 2019 KernelVersion: 5.3 -Contact: Marek Behún +Contact: Marek Behún Description: (Read) Moxtet module name. Format: string diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia index 795a5de12fc1..c4d46970c1cf 100644 --- a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia +++ b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia @@ -1,7 +1,7 @@ What: /sys/class/leds//device/brightness Date: July 2020 KernelVersion: 5.9 -Contact: Marek Behún +Contact: Marek Behún Description: (RW) On the front panel of the Turris Omnia router there is also a button which can be used to control the intensity of all the LEDs at once, so that if they are too bright, user can dim them. diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm index b8631f5a29c4..ea5e5b489bc7 100644 --- a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm +++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm @@ -1,21 +1,21 @@ What: /sys/firmware/turris-mox-rwtm/board_version Date: August
[PATCH 1/2] MAINTAINERS: update CZ.NIC's Turris information
Add all the files maintained by Turris team, not only for MOX, but also for Omnia. Change website. Signed-off-by: Marek Behún --- MAINTAINERS | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8d23b0ec0c90..2cf388c89196 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1790,19 +1790,26 @@ F: drivers/net/ethernet/cortina/ F: drivers/pinctrl/pinctrl-gemini.c F: drivers/rtc/rtc-ftrtc010.c -ARM/CZ.NIC TURRIS MOX SUPPORT +ARM/CZ.NIC TURRIS SUPPORT M: Marek Behun S: Maintained -W: http://mox.turris.cz +W: https://www.turris.cz/ F: Documentation/ABI/testing/debugfs-moxtet F: Documentation/ABI/testing/sysfs-bus-moxtet-devices F: Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm F: Documentation/devicetree/bindings/bus/moxtet.txt F: Documentation/devicetree/bindings/firmware/cznic,turris-mox-rwtm.txt F: Documentation/devicetree/bindings/gpio/gpio-moxtet.txt +F: Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +F: Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt F: drivers/bus/moxtet.c F: drivers/firmware/turris-mox-rwtm.c +F: drivers/leds/leds-turris-omnia.c +F: drivers/mailbox/armada-37xx-rwtm-mailbox.c F: drivers/gpio/gpio-moxtet.c +F: drivers/watchdog/armada_37xx_wdt.c +F: include/dt-bindings/bus/moxtet.h +F: include/linux/armada-37xx-rwtm-mailbox.h F: include/linux/moxtet.h ARM/EZX SMARTPHONES (A780, A910, A1200, E680, ROKR E2 and ROKR E6) -- 2.26.2
Re: [PATCH mvebu v2 09/10] cpufreq: armada-37xx: Remove cur_frequency variable
On Mon, 29 Mar 2021 17:00:12 +0200 Gregory CLEMENT wrote: > Pali Rohár writes: > > > Variable cur_frequency in armada37xx_cpufreq_driver_init() is unused. > > > > Signed-off-by: Pali Rohár > > Acked-by: Gregory CLEMENT Gregory, THX for the acks. Will you be merging these patches or should this be done by someone else? cpufreq maintainers maybe? Marek
Re: [PATCH] PCI: Disallow retraining link for Atheros QCA98xx chips on non-Gen1 PCIe bridges
On Sat, 27 Mar 2021 14:29:59 +0100 Pali Rohár wrote: > I can change this to 'if (!ret)' if needed, no problem. > > I use 'if (!val)' mostly for boolean and pointer variables. If > variable can contain more integer values then I lot of times I use > '=='. Comparing integer varibales with explicit literals is sensible, but if a function returning integer returns 0 on success and negative value on error, Linux kernel has a tradition of using just if (!ret) or if (ret) Marek
Re: [PATCH v2] net: phy: marvell: fix detection of PHY on Topaz switches
> + /* Some internal PHYs don't have a model number. */
> + if (reg == MII_PHYSID2 && !(val & 0x3f0) &&
> + chip->info->family < ARRAY_SIZE(family_prod_id_table)) {
> + prod_id = family_prod_id_table[chip->info->family];
> + if (prod_id)
> + val |= prod_id >> 4;
Isn't if(prod_id) check redundant here? If prod_id is 0, the |=
statement won't do anything.
Marek
Re: [PATCH net-next 1/2] net: phy: marvell-88x2222: check that link is operational
On Mon, 12 Apr 2021 15:16:59 +0300
Ivan Bornyakov wrote:
> Some SFP modules uses RX_LOS for link indication. In such cases link
> will be always up, even without cable connected. RX_LOS changes will
> trigger link_up()/link_down() upstream operations. Thus, check that SFP
> link is operational before actual read link status.
>
> Signed-off-by: Ivan Bornyakov
> ---
> drivers/net/phy/marvell-88x.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/net/phy/marvell-88x.c
> b/drivers/net/phy/marvell-88x.c
> index eca8c2f20684..fb285ac741b2 100644
> --- a/drivers/net/phy/marvell-88x.c
> +++ b/drivers/net/phy/marvell-88x.c
> @@ -51,6 +51,7 @@
> struct mv_data {
> phy_interface_t line_interface;
> __ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
> + bool sfp_link;
> };
>
> /* SFI PMA transmit enable */
> @@ -148,6 +149,9 @@ static int mv_read_status(struct phy_device *phydev)
> phydev->speed = SPEED_UNKNOWN;
> phydev->duplex = DUPLEX_UNKNOWN;
>
> + if (!priv->sfp_link)
> + return 0;
> +
So if SFP is not used at all, if this PHY is used in a different
usecase, this function will always return 0? Is this correct?
> if (priv->line_interface == PHY_INTERFACE_MODE_10GBASER)
> link = mv_read_status_10g(phydev);
> else
> @@ -446,9 +450,31 @@ static void mv_sfp_remove(void *upstream)
> linkmode_zero(priv->supported);
> }
>
> +static void mv_sfp_link_up(void *upstream)
> +{
> + struct phy_device *phydev = upstream;
> + struct mv_data *priv;
> +
> + priv = (struct mv_data *)phydev->priv;
> +
> + priv->sfp_link = true;
> +}
> +
> +static void mv_sfp_link_down(void *upstream)
> +{
> + struct phy_device *phydev = upstream;
> + struct mv_data *priv;
> +
> + priv = (struct mv_data *)phydev->priv;
This cast is redundant since the phydev->priv is (void*). You can cast
(void*) to (struct ... *).
You can also just use
struct mv_data *priv = phydev->priv;
> +
> + priv->sfp_link = false;
> +}
> +
> static const struct sfp_upstream_ops sfp_phy_ops = {
> .module_insert = mv_sfp_insert,
> .module_remove = mv_sfp_remove,
> + .link_up = mv_sfp_link_up,
> + .link_down = mv_sfp_link_down,
> .attach = phy_sfp_attach,
> .detach = phy_sfp_detach,
> };
Re: [PATCH] net: phy: marvell: fix detection of PHY on Topaz switches
On Mon, 12 Apr 2021 18:38:29 +0200
Pali Rohár wrote:
> On Monday 12 April 2021 18:12:35 Andrew Lunn wrote:
> > On Mon, Apr 12, 2021 at 05:52:39PM +0200, Pali Rohár wrote:
> > > On Monday 12 April 2021 17:32:33 Andrew Lunn wrote:
> > > > > Anyway, now I'm looking at phy/marvell.c driver again and it supports
> > > > > only 88E6341 and 88E6390 families from whole 88E63xxx range.
> > > > >
> > > > > So do we need to define for now table for more than
> > > > > MV88E6XXX_FAMILY_6341 and MV88E6XXX_FAMILY_6390 entries?
> > > >
> > > > Probably not. I've no idea if the 6393 has an ID, so to be safe you
> > > > should add that. Assuming it has a family of its own.
> > >
> > > So what about just?
> > >
> > > if (reg == MII_PHYSID2 && !(val & 0x3f0)) {
> > > if (chip->info->family == MV88E6XXX_FAMILY_6341)
> > > val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6341 >> 4;
> > > else if (chip->info->family == MV88E6XXX_FAMILY_6390)
> > > val |= MV88E6XXX_PORT_SWITCH_ID_PROD_6390 >> 4;
> > > }
> >
> > As i said, i expect the 6393 also has no ID. And i recently found out
> > Marvell have some automotive switches, 88Q5xxx which are actually
> > based around the same IP and could be added to this driver. They also
> > might not have an ID. I suspect this list is going to get longer, so
> > having it table driven will make that simpler, less error prone.
> >
> > Andrew
>
> Ok, I will use table but I fill it only with Topaz (6341) and Peridot
> (6390) which was there before as I do not have 6393 switch for testing.
>
> If you or anybody else has 6393 unit for testing, please extend then
> table.
6393 PHYs report PHY ID 0x002b0808, I.e. no model number.
I now realize that I did not implement this for 6393, these PHYs are
detected as
mv88e6085 ... PHY [...] driver [Generic PHY] (irq=POLL)
And it seems that this temperature sensor is different from 1510, 6341
and 6390 :) I will look into this and send a patch.
Marek
Re: [PATCH AUTOSEL 5.11 17/23] i2c: mv64xxx: Fix random system lock caused by runtime PM
On Mon, 19 Apr 2021 16:43:36 -0400
Sasha Levin wrote:
> This first appeared with commit e5c02cf54154 ("i2c: mv64xxx: Add runtime
> PM support").
I forgot to add Fixes: tag to this commit. But the bug first appeared with
commit
e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support")
which is in 5.12, but not 5.11 or any others.
So this fix is not needed for the stable releases (althogh it does not
break anything on those...).
Marek
Re: [PATCH mvebu v3 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Fri, 12 Mar 2021 10:12:06 +0100 Gregory CLEMENT wrote: > Hello Pali, > > > Hello Gregory! > > > > Patches are the for almost two months and more people have tested them. > > They are marked with Fixed/CC-stable tags, they should go also into > > stable trees as they are fixing CPU scaling and instability issues. > > > > Are there any issues with these patches? If not, could you please merge > > them for upcoming Linux version? > > Actually I am not the maintainer of the clk and cpufreq subsystems, so > the only thing I can apply is the device tree relative patch. > > Gregory Gregory, could you at least add Acked-by, or Reviewed-by? So that clk subsystem maintainer will trust these changes, since you are the original author of armada-37xx-periph. Marek
Re: [net-next PATCH v12 4/4] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell
On Fri, 11 Dec 2020 22:51:01 +1000
Pavana Sharma wrote:
> +int mv88e6393x_serdes_irq_enable(struct mv88e6xxx_chip *chip, int port,
> + int lane, bool enable)
> +{
> + u8 cmode = chip->ports[port].cmode;
> + int err = 0;
> +
> + switch (cmode) {
> + case MV88E6XXX_PORT_STS_CMODE_SGMII:
> + case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
> + case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
> + case MV88E6XXX_PORT_STS_CMODE_5GBASER:
> + case MV88E6XXX_PORT_STS_CMODE_10GBASER:
> + err = mv88e6390_serdes_irq_enable_sgmii(chip, lane, enable);
> + }
This is wrong. IRQ for 5gbase-r and 10gbase-r is enabled differently.
Please look at how I did it in my proposal
https://www.mail-archive.com/netdev@vger.kernel.org/msg347854.html
Please look at the following functions in that patch:
mv88e6393x_serdes_irq_enable_10g()
mv88e6393x_serdes_irq_enable()
mv88e6393x_serdes_irq_status_10g()
irqreturn_t mv88e6393x_serdes_irq_status()
and also at the constants added to serdes.h in that patch
#define MV88E6393X_10G_INT_ENABLE 0x9000
#define MV88E6393X_10G_INT_LINK_CHANGE BIT(2)
#define MV88E6393X_10G_INT_STATUS 0x9001
Re: [net-next PATCH v12 4/4] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell
On Wed, 6 Jan 2021 10:45:30 +1000 Pavana Sharma wrote: > Thanks Marek for catching this. > > I will have a closer look and update the patchset. I also sent a reply patch with subject "patch fixing mv88e6393x SERDES IRQ for Pavana's series" it contains the changes necessary to your series. Please look at that. You can apply it to your commit via patch -p1
Re: [PATCH RFC] ARM64: dts: marvell: Add DTS file for Turris Mox
On Fri, 18 Jan 2019 15:35:35 +0100 Gregory CLEMENT wrote: > > The basic module can be extended by different modules. > > When those modules are connected, U-Boot has to let kernel know via > > device-tree. Since modules can be connected in different order and > > some modules can be connected multiple times (up to three 8-port > > switch modules can be connected), using dtb overlays would result in > > too files. > > What do you mean by too many files? > > The dtb overlays seems really matches your situation. > Usually we have one dtb part by module and then we mix them together. > > Gregory Hi Gregory, the problem is that in some cases here some even if you have the same module, some parameters have to be different depending on which position the module is in the topology and what type of module is before it. For example up to three switch modules can be connected one after another, and although physically they are the same, their dtb parameters (MDIO address and whether they are connected to CPU or another switch module) are different. So if I wanter to use overlays without dtb modification from u-boot, I would have to have three overlays for Peridot module, for topologies: peridot peridot-peridot peridot-peridot-peridot three for Topaz module: topaz peridot-topaz peridot-peridot-topaz and four for SFP module: sfp peridot-sfp peridot-peridot-sfp peridot-peridot-peridot-sfp For the PCIe and USB module this is not the case, only one overlay for each. But I thought (and still think) that in this case it is more elegant to just enable the modules in U-Boot than to use so many different overlays. And since I already thought up this solution for SFP and switch modules, I used it for the PCIe and USB modules as well, instead of mixing overlays there. I am of course willing to rewrite this to use overlays, if you guys are unwilling to merge it done this way, but I think this solution is better. Also, I would like to have the dts definitions for all modules officially supported by Mox to have in the kernel, and if this was done via overlays, it would not be merged, or am I wrong? Are there overlay dts sources for some device in the kernel? Marek
[PATCH v4 armsoc/drivers/bus+gpio 5/5] dt-bindings: gpio: Document GPIOs via Moxtet bus
This patch adds documentation of the device tree bindings for GPIOs
on the devices connected via Moxtet bus.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/gpio/gpio-moxtet.txt | 18 ++
MAINTAINERS| 1 +
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
new file mode 100644
index ..410759de9f09
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
@@ -0,0 +1,18 @@
+Turris Mox Moxtet GPIO expander via Moxtet bus
+
+Required properties:
+ - compatible : Should be "cznic,moxtet-gpio".
+ - gpio-controller : Marks the device node as a GPIO controller.
+ - #gpio-cells : Should be two. For consumer use see gpio.txt.
+
+Other properties are required for a Moxtet bus device, please refer to
+Documentation/devicetree/bindings/bus/moxtet.txt.
+
+Example:
+
+ moxtet_sfp: gpio@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
diff --git a/MAINTAINERS b/MAINTAINERS
index 6af384154ce5..ccb979f64431 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1505,6 +1505,7 @@ S:Maintained
F: Documentation/ABI/testing/debugfs-moxtet
F: Documentation/ABI/testing/sysfs-bus-moxtet-devices
F: Documentation/devicetree/bindings/bus/moxtet.txt
+F: Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
F: drivers/gpio/gpio-moxtet.c
--
2.19.2
[PATCH v4 armsoc/drivers/bus+gpio 1/5] bus: Add support for Moxtet bus
On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a PCIe pass-through MiniPCIe connector module, a 4-port
switch module, an 8-port switch module, and a 4-port USB3 module.
For example:
[CPU]-[PCIe-pass-through]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]
Each of this modules has an input and output shift register, and these
are connected via SPI to the CPU board.
Via SPI we are able to discover which modules are connected, in which
order, and we can also read some information about the modules (eg.
their interrupt status), and configure them.
>From each module 8 bits can be read (of which low 4 bits identify the
module) and 8 bits can be written.
For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.
This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them.
It also implements a virtual interrupt controller for the modules which
send their interrupt status over the SPI shift register. These modules
do this in addition to sending their interrupt status via the shared
interrupt line. When the shared interrupt is triggered, we read from the
shift register and handle IRQs for all devices which are in interrupt.
The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.
Signed-off-by: Marek Behún
---
MAINTAINERS | 7 +
drivers/bus/Kconfig | 10 +
drivers/bus/Makefile | 1 +
drivers/bus/moxtet.c | 886 +++
include/dt-bindings/bus/moxtet.h | 16 +
include/linux/moxtet.h | 109
6 files changed, 1029 insertions(+)
create mode 100644 drivers/bus/moxtet.c
create mode 100644 include/dt-bindings/bus/moxtet.h
create mode 100644 include/linux/moxtet.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a419acaa01c5..d96d36c83bc3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1498,6 +1498,13 @@ F: drivers/clocksource/timer-atlas7.c
N: [^a-z]sirf
X: drivers/gnss
+ARM/CZ.NIC TURRIS MOX SUPPORT
+M: Marek Behun
+W: http://mox.turris.cz
+S: Maintained
+F: include/linux/moxtet.h
+F: drivers/bus/moxtet.c
+
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112ccc29..6b331061d34b 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -29,6 +29,16 @@ config BRCMSTB_GISB_ARB
arbiter. This driver provides timeout and target abort error handling
and internal bus master decoding.
+config MOXTET
+ tristate "CZ.NIC Turris Mox module configuration bus"
+ depends on SPI_MASTER && OF
+ help
+ Say yes here to add support for the module configuration bus found
+ on CZ.NIC's Turris Mox. This is needed for the ability to discover
+ the order in which the modules are connected and to get/set some of
+ their settings. For example the GPIOs on Mox SFP module are
+ configured through this bus.
+
config HISILICON_LPC
bool "Support for ISA I/O space on HiSilicon Hip06/7"
depends on ARM64 && (ARCH_HISI || COMPILE_TEST)
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ca300b1914ce..16b43d3468c6 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_HISILICON_LPC)+= hisi_lpc.o
obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o
+obj-$(CONFIG_MOXTET) += moxtet.o
# DPAA2 fsl-mc bus
obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/moxtet.c b/drivers/bus/moxtet.c
new file mode 100644
index ..1ee4570e7e17
--- /dev/null
+++ b/drivers/bus/moxtet.c
@@ -0,0 +1,886 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox module configuration bus driver
+ *
+ * Copyright (C) 2019 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * @name: module name for sysfs
+ * @hwirq_base:base index for IRQ for this module (-1 if no IRQs)
+ * @nirqs: how many interrupts does the shift register provide
+ * @desc: module description for kernel log
+ */
+static const struct {
+ const char *name;
+ int hwirq_base;
+ int nirqs;
+ const char *desc;
+} mox_module_table[] = {
+ /* do not change order of this array! */
+ { NULL, 0, 0, NULL },
+ { "sfp",-1, 0, "MOX D (SFP cage)" },
+ { "pci",MOXTET
[PATCH v4 armsoc/drivers/bus+gpio 4/5] drivers: gpio: Add support for GPIOs over Moxtet bus
This adds support for interpreting the input and output bits of one
device on Moxtet bus as GPIOs.
This is needed for example by the SFP cage module of Turris Mox.
Signed-off-by: Marek Behún
Reviewed-by: Linus Walleij
---
MAINTAINERS| 1 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-moxtet.c | 179 +
4 files changed, 190 insertions(+)
create mode 100644 drivers/gpio/gpio-moxtet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 43de8eaa284b..6af384154ce5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1507,6 +1507,7 @@ F:
Documentation/ABI/testing/sysfs-bus-moxtet-devices
F: Documentation/devicetree/bindings/bus/moxtet.txt
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
+F: drivers/gpio/gpio-moxtet.c
ARM/EBSA110 MACHINE SUPPORT
M: Russell King
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b5a2845347ec..2c9ffa0e2287 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1400,6 +1400,15 @@ config GPIO_XRA1403
help
GPIO driver for EXAR XRA1403 16-bit SPI-based GPIO expander.
+config GPIO_MOXTET
+ tristate "Turris Mox Moxtet bus GPIO expander"
+ depends on MOXTET
+ help
+ Say yes here if you are building for the Turris Mox router.
+ This is the driver needed for configuring the GPIOs via the Moxtet
+ bus. For example the Mox module with SFP cage needs this driver
+ so that phylink can use corresponding GPIOs.
+
endmenu
menu "USB GPIO expanders"
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 37628f8dbf70..3d0b28cbf62c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60) += gpio-mc9s08dz60.o
obj-$(CONFIG_GPIO_ML_IOH) += gpio-ml-ioh.o
obj-$(CONFIG_GPIO_MM_LANTIQ) += gpio-mm-lantiq.o
obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
+obj-$(CONFIG_GPIO_MOXTET) += gpio-moxtet.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxtet.c b/drivers/gpio/gpio-moxtet.c
new file mode 100644
index ..3fd729994a38
--- /dev/null
+++ b/drivers/gpio/gpio-moxtet.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Turris Mox Moxtet GPIO expander
+ *
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+
+#define MOXTET_GPIO_NGPIOS 12
+#define MOXTET_GPIO_INPUTS 4
+
+struct moxtet_gpio_desc {
+ u16 in_mask;
+ u16 out_mask;
+};
+
+static const struct moxtet_gpio_desc descs[] = {
+ [TURRIS_MOX_MODULE_SFP] = {
+ .in_mask = GENMASK(2, 0),
+ .out_mask = GENMASK(5, 4),
+ },
+};
+
+struct moxtet_gpio_chip {
+ struct device *dev;
+ struct gpio_chipgpio_chip;
+ const struct moxtet_gpio_desc *desc;
+};
+
+static int moxtet_gpio_get_value(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int ret;
+
+ if (chip->desc->in_mask & BIT(offset)) {
+ ret = moxtet_device_read(chip->dev);
+ } else if (chip->desc->out_mask & BIT(offset)) {
+ ret = moxtet_device_written(chip->dev);
+ if (ret >= 0)
+ ret <<= MOXTET_GPIO_INPUTS;
+ } else {
+ return -EINVAL;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ return !!(ret & BIT(offset));
+}
+
+static void moxtet_gpio_set_value(struct gpio_chip *gc, unsigned int offset,
+ int val)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+ int state;
+
+ state = moxtet_device_written(chip->dev);
+ if (state < 0)
+ return;
+
+ offset -= MOXTET_GPIO_INPUTS;
+
+ if (val)
+ state |= BIT(offset);
+ else
+ state &= ~BIT(offset);
+
+ moxtet_device_write(chip->dev, state);
+}
+
+static int moxtet_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ /* All lines are hard wired to be either input or output, not both. */
+ if (chip->desc->in_mask & BIT(offset))
+ return 1;
+ else if (chip->desc->out_mask & BIT(offset))
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static int moxtet_gpio_direction_input(struct gpio_chip *gc,
+ unsigned int offset)
+{
+ struct moxtet_gpio_chip *chip = gpiochip_get_data(gc);
+
+ if (chip->desc->in_mask & BIT(offset))
+ return 0;
+ else if (
[PATCH v4 armsoc/drivers/bus+gpio 2/5] dt-bindings: bus: Document moxtet bus binding
This adds device tree binding documentation for the Moxtet bus, a bus
via which the different modules connected to the Turris Mox router can
be configured.
Signed-off-by: Marek Behún
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/bus/moxtet.txt| 44 +++
MAINTAINERS | 1 +
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt
diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt
b/Documentation/devicetree/bindings/bus/moxtet.txt
new file mode 100644
index ..7be9d00c1767
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/moxtet.txt
@@ -0,0 +1,44 @@
+Turris Mox module status and configuration bus (over SPI)
+
+Required properties:
+ - compatible : Should be "cznic,moxtet"
+ - #address-cells : Has to be 1
+ - #size-cells : Has to be 0
+ - spi-cpol: Required inverted clock polarity
+ - spi-cpha: Required shifted clock phase
+ - interrupts : Must contain reference to the shared interrupt line
+ - interrupt-controller: Required
+ - #interrupt-cells: Has to be 1
+
+For other required and optional properties of SPI slave nodes please refer to
+../spi/spi-bus.txt.
+
+Required properties of subnodes:
+ - reg : Should be position on the Moxtet bus
+
+The driver finds the devices connected to the bus by itself, but it may be
+needed to reference some of them from other parts of the device tree. In that
+case the devices can be defined as subnodes of the moxtet node.
+
+Example:
+
+ moxtet@1 {
+ compatible = "cznic,moxtet";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gpiosb>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ moxtet_sfp: gpio@0 {
+ compatible = "cznic,moxtet-sfp";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ }
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index d96d36c83bc3..3f461a2d776a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1502,6 +1502,7 @@ ARM/CZ.NIC TURRIS MOX SUPPORT
M: Marek Behun
W: http://mox.turris.cz
S: Maintained
+F: Documentation/devicetree/bindings/bus/moxtet.txt
F: include/linux/moxtet.h
F: drivers/bus/moxtet.c
--
2.19.2
[PATCH v4 armsoc/drivers/bus+gpio 3/5] bus: moxtet: Add sysfs and debugfs documentation
Add sysfs ABI documentation for the attribute files module_id and module_name Add debugfs ABI documentation for reading input from the shift registers and reading last written output or write output to the shift registers. Signed-off-by: Marek Behún --- Documentation/ABI/testing/debugfs-moxtet | 23 +++ .../ABI/testing/sysfs-bus-moxtet-devices | 17 ++ MAINTAINERS | 2 ++ 3 files changed, 42 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-moxtet create mode 100644 Documentation/ABI/testing/sysfs-bus-moxtet-devices diff --git a/Documentation/ABI/testing/debugfs-moxtet b/Documentation/ABI/testing/debugfs-moxtet new file mode 100644 index ..32a02e7d0f4e --- /dev/null +++ b/Documentation/ABI/testing/debugfs-moxtet @@ -0,0 +1,23 @@ +What: /sys/kernel/debug/moxtet/input +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Read input from the shift registers, in hexadecimal. + Returns N+1 bytes, where N is the number of Moxtet connected + modules. The first byte is from the CPU board itself. + Example: 101214 +10: CPU board with SD card +12: 2 = PCIe module, 1 = IRQ not active +14: 4 = Peridot module, 1 = IRQ not active + +What: /sys/kernel/debug/moxtet/output +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (RW) Read last written value to the shift registers, in + hexadecimal, or write values to the shift registers, also + in hexadecimal. + Example: 0102 +01: 01 was last written, or is to be written, to the +first module's shift register +02: the same for second module diff --git a/Documentation/ABI/testing/sysfs-bus-moxtet-devices b/Documentation/ABI/testing/sysfs-bus-moxtet-devices new file mode 100644 index ..3e3256b37a3c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-moxtet-devices @@ -0,0 +1,17 @@ +What: /sys/bus/moxtet/devices/moxtet-./module_description +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Moxtet module description. Format: string + +What: /sys/bus/moxtet/devices/moxtet-./module_id +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Moxtet module ID. Format: %x + +What: /sys/bus/moxtet/devices/moxtet-./module_name +Date: March 2019 +KernelVersion: 5.2 +Contact: Marek Behún +Description: (R) Moxtet module name. Format: string diff --git a/MAINTAINERS b/MAINTAINERS index 3f461a2d776a..43de8eaa284b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1502,6 +1502,8 @@ ARM/CZ.NIC TURRIS MOX SUPPORT M: Marek Behun W: http://mox.turris.cz S: Maintained +F: Documentation/ABI/testing/debugfs-moxtet +F: Documentation/ABI/testing/sysfs-bus-moxtet-devices F: Documentation/devicetree/bindings/bus/moxtet.txt F: include/linux/moxtet.h F: drivers/bus/moxtet.c -- 2.19.2
[PATCH v4 armsoc/drivers/bus+gpio 0/5] Add Moxtet bus and GPIO over Moxtet bus
Hello, this is the fourth version of patches to support the Moxtet bus and GPIOs over it. Moxtet is a Turris Mox specific tiny bus over SPI. I know that merge window is now closed, but I am trying this anyway now, since Documentation/process/2.Process.rst mentions that even when merge window is closed, "An occasional exception is made for drivers for previously-unsupported hardware; if they touch no in-tree code, they cannot cause regressions and should be safe to add at any time." These patches apply to current linux/master, linux-gpio/devel and arm-soc/arm/drivers. I would appreciate reviews for the changes I made. I removed the Acked-by, since the changes in drivers/bus/moxtet.c are non-trivial. Marek Changes since v3: - added module_description file in /sys/bus/moxtet/devices/*/ - moved debugging into debugfs: - removed input_value and output_value debug files from /sys/bus/moxtet/devices/*/ - added input and output debug files to debugfs/moxtet - added support for interrupts into moxtet driver: Some modules send interrupt via a shared line for all modules. In addition to this, they also send interrupt information via the SPI shift register, so that the system can distinguish which modules exactly sent it and won't have to check all modules. This is also needed to fix some bugs when one module sent IRQ and then another module sent another IRQ before the first was handled by the system, but the handling was already in progress. Since the shared line is falling-edge, the second IRQ was never handled. - since moxtet driver is now also interrupt controller, device-tree binding documentation is also changed Changes since v2: - addressed the issues in device tree documentation pointed by Rob Herring - cosmetic changes suggested by Linus Walleij - added sysfs ABI documentation for /sys/bus/moxtet/devices attribute files as suggested by Linus Walleij Marek Behún (5): bus: Add support for Moxtet bus dt-bindings: bus: Document moxtet bus binding bus: moxtet: Add sysfs and debugfs documentation drivers: gpio: Add support for GPIOs over Moxtet bus dt-bindings: gpio: Document GPIOs via Moxtet bus Documentation/ABI/testing/debugfs-moxtet | 23 + .../ABI/testing/sysfs-bus-moxtet-devices | 17 + .../devicetree/bindings/bus/moxtet.txt| 44 + .../devicetree/bindings/gpio/gpio-moxtet.txt | 18 + MAINTAINERS | 12 + drivers/bus/Kconfig | 10 + drivers/bus/Makefile | 1 + drivers/bus/moxtet.c | 886 ++ drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-moxtet.c| 179 include/dt-bindings/bus/moxtet.h | 16 + include/linux/moxtet.h| 109 +++ 13 files changed, 1325 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-moxtet create mode 100644 Documentation/ABI/testing/sysfs-bus-moxtet-devices create mode 100644 Documentation/devicetree/bindings/bus/moxtet.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-moxtet.txt create mode 100644 drivers/bus/moxtet.c create mode 100644 drivers/gpio/gpio-moxtet.c create mode 100644 include/dt-bindings/bus/moxtet.h create mode 100644 include/linux/moxtet.h -- 2.19.2
Re: [PATCH RFC] leds: Add support for per-LED device triggers
On Thu, 2 Jul 2020 16:47:11 +0200
Ondrej Jirman wrote:
> Some LED controllers may come with an internal HW triggering mechanism
> for the LED and an ability to switch between user control of the LED,
> or the internal control. One such example is AXP20X PMIC, that allows
> wither for user control of the LED, or for internal control based on
> the state of the battery charger.
>
> Add support for registering per-LED device trigger.
>
> Names of private triggers need to be globally unique, but may clash
> with other private triggers. This is enforced during trigger
> registration. Developers can register private triggers just like
> the normal triggers, by setting private_led to a classdev
> of the LED the trigger is associated with.
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/leds/led-triggers.c | 12 +---
> include/linux/leds.h| 3 +++
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index 79e30d2cb7a5..3011e2658404 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -50,7 +50,8 @@ ssize_t led_trigger_write(struct file *filp, struct
> kobject *kobj,
> down_read(&triggers_list_lock);
> list_for_each_entry(trig, &trigger_list, next_trig) {
> - if (sysfs_streq(buf, trig->name)) {
> + if (sysfs_streq(buf, trig->name) &&
> + (!trig->private_led || trig->private_led ==
> led_cdev)) { down_write(&led_cdev->trigger_lock);
> led_trigger_set(led_cdev, trig);
> up_write(&led_cdev->trigger_lock);
> @@ -96,6 +97,9 @@ static int led_trigger_format(char *buf, size_t
> size, bool hit = led_cdev->trigger &&
> !strcmp(led_cdev->trigger->name, trig->name);
>
> + if (trig->private_led && trig->private_led !=
> led_cdev)
> + continue;
> +
> len += led_trigger_snprintf(buf + len, size - len,
> " %s%s%s", hit ? "[" :
> "", trig->name, hit ? "]" : "");
> @@ -243,7 +247,8 @@ void led_trigger_set_default(struct led_classdev
> *led_cdev) down_read(&triggers_list_lock);
> down_write(&led_cdev->trigger_lock);
> list_for_each_entry(trig, &trigger_list, next_trig) {
> - if (!strcmp(led_cdev->default_trigger, trig->name)) {
> + if (!strcmp(led_cdev->default_trigger, trig->name) &&
> + (!trig->private_led || trig->private_led ==
> led_cdev)) { led_cdev->flags |= LED_INIT_DEFAULT_TRIGGER;
> led_trigger_set(led_cdev, trig);
> break;
> @@ -280,7 +285,8 @@ int led_trigger_register(struct led_trigger *trig)
> down_write(&triggers_list_lock);
> /* Make sure the trigger's name isn't already in use */
> list_for_each_entry(_trig, &trigger_list, next_trig) {
> - if (!strcmp(_trig->name, trig->name)) {
> + if (!strcmp(_trig->name, trig->name) &&
> + (!_trig->private_led || _trig->private_led ==
> trig->private_led)) { up_write(&triggers_list_lock);
> return -EEXIST;
> }
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 2451962d1ec5..0d7577c752ad 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -345,6 +345,9 @@ struct led_trigger {
> int (*activate)(struct led_classdev
> *led_cdev); void (*deactivate)(struct led_classdev
> *led_cdev);
> + /* LED-private triggers have the LED device set here. */
> + struct led_classdev *private_led;
> +
> /* LEDs under control by this trigger (for simple triggers)
> */ rwlock_t leddev_list_lock;
> struct list_head led_cdevs;
Hi Ondrej,
Some criticism to this approach to HW triggers:
- every hw trigger for each LED has to be registered via current trigger
API. This will grow code size and memory footprint once this API is
widely used
- one HW trigger can only master one LED device (via private_led
member). So if I have, for example an ethernet switch with 8 ports,
and each port has 2 LEDs, and each LED has 10 possible HW triggering
mechanisms, with your proposed API one would need to register 8*2*10
= 160 triggers
I too have been thinking about an API for HW LED triggers, and I
tinkered with it a little. Some time ago I sent some emails, with
subjects:
"RFC: LED hw triggering API"
"about my trigger-sources work"
My current thoughts about how HW LED triggers could work nicely is as
such:
- these members (maybe with different names) shall be added to struct
led_classdev:
available_hw_triggers()
- shall return a NULL terminated list of HW trigger names
available for this LED
set_hw_trigger()
- sets HW trigger for this LED. The LED triggering API shall
call this method after previous LED trigger is unset. If
called
Re: [PATCH RFC] leds: Add support for per-LED device triggers
Hi Ondrej, I overlooked your reply in my inbox, sorry this took so long. On Fri, 3 Jul 2020 15:08:09 +0200 Ondřej Jirman wrote: > Do you have such a switch? Also what's your real usecase? Yes, on Turris MOX three 8-port ethernet switches can be plugged, resulting in 24 ethernet ports, each having 2 LEDs. The current driver does not expose these LEDs via sysfs, but I want to add the support there. Each of these LEDs can be controlled by software, or can be put into one of these HW controlled modes: - Link (with three submodes: 10/100, Gb, 10Gb) - Link activity (again with three submodes as above) - PTP activity - Force blink > My usecase is a PMIC which has either a user-controllable or > self-working mode for a single LED it controls. I want to be able to > switch between those quickly and easily. I understand your usecase completely. This is the same thing I want. I just have reservations about how you want to implement this. Marek > I want the LED to be mostly controlled by PMIC, because that way PMIC > can signal events that are not exposed to OS like overvoltage, > overheating, etc. ... all automagically, but also be able to control > it sometimes via SW (for non PMIC related notifications, eg.). > > So in my mindset LED is either controlled by Linux via various SW > triggers, or it's self-working in some arbitrary device specific > configuration that doesn't need any passing of the data via CPU for > the LED to reflect some HW state. > > So I'd expose a 'hw-trigger' only on the LED device that allows this, > that you can select among all the other regular triggers as you do > now, and then configure its precise mode/options in sysfs (on the > trigger kobj). The driver would come with some sane device specific > defaults for the self-working mode. > > User can then select hw-trigger, in the triggers and would get a nice > PMIC LED behavior controlled by HW, or a common LED behavior of the > ehternet port, or on the wireless card, or whatever. > > From the perspective of this use case the interface is nice and > generic: > > - you set LED to hw-trigger mode on boot > - you set trigger to none and poke the LED with a pattern you want > for the notification and put it back to hw-trigger mode again > afterwards > > We can standardize on hw-trigger, or self-controlled, or some other > name for this kind of private LED trigger, and then the userspace > would not need to even care about the specific LED device type, when > sitching between SW controlled and self-working modes. > > You'd be able to take SW control of the ethernet PHY controlled LEDs > this way just the same as the PMIC LED with the same interface, > described above. And if you don't like the default self-controled > mode, you can change it via sysfs attributes on the trigger. > > It would also allow the user to switch between SW and HW control, > without having to remember the previous HW triggering mode, because > that could be persisted by the LED HW trigger device. So you can go > back to previous HW triggering mode just by 'echo hw-trigger > > your-led/trigger'. > > I've read through the discussions, and this seems like a workable > interface. > > Most of the LED devices would just add one extra private trigger to > the triggers_list, so it would not explode in the way you describe > above. > > Also benefit of this approach is that it fits quite nicely with the > existing code, and requires minimal changes. The trigger already > allows for specifying sysfs attributes, too. > > regards, > o.
Re: [PATCH RFC] leds: Add support for per-LED device triggers
On Sat, 4 Jul 2020 14:59:00 +0200 Pavel Machek wrote: > Hi! > > > Some criticism to this approach to HW triggers: > > - every hw trigger for each LED has to be registered via current > > trigger API. This will grow code size and memory footprint once > > this API is widely used > > - one HW trigger can only master one LED device (via private_led > > member). So if I have, for example an ethernet switch with 8 > > ports, and each port has 2 LEDs, and each LED has 10 possible HW > > triggering mechanisms, with your proposed API one would need to > > register 8*2*10 = 160 triggers > > Well, code is simple, and so far I have seen 2 HW triggering > mechanisms, not 10. Maybe we should have a function to regiter a hw > trigger for a LED, so that internal implementation can be changed > more easily. > > Ondrej: You already have code using this, right? Can we get an > example? > > > I too have been thinking about an API for HW LED triggers, and I > > tinkered with it a little. Some time ago I sent some emails, with > > subjects: > > "RFC: LED hw triggering API" > > "about my trigger-sources work" > > Perhaps it is time to send them one more time, so Ondrej can say if it > works for him/looks okay for him? > > > My current thoughts about how HW LED triggers could work nicely is > > as such: > > - these members (maybe with different names) shall be added to > > struct led_classdev: > > available_hw_triggers() > > - shall return a NULL terminated list of HW trigger names > > available for this LED > > set_hw_trigger() > > - sets HW trigger for this LED. The LED triggering API shall > > call this method after previous LED trigger is unset. If > > called with NULL parameter, unsets HW trigger > > current_hw_trigger > > - name of the currently set HW LED trigger for this LED > > - the driver registering the LED cdev informs abouth the LED being > > capable of HW triggering - members available_hw_triggers and > > set_hw_trigger must be set > > - SW LED trigger and HW LED trigger are mutualy exclusive on one > > LED > > - the trigger file in sysfs (/sys/class/leds/LED/trigger) shall > > first list the available SW triggers, and then available hw > > triggers for this LED, prefixed with "hw:" > > When written, if the written trigger name starts with "hw:", > > instead of setting SW trigger, a HW trigger is set via > > set_hw_trigger() method > > This does not sound bad, either. > > Best regards, > Pavel Hi Pavel I shall try to implement this and send a proposal within 2 weeks. Marek
Re: [PATCH] net: phy: marvell: Use phy_read_paged() instead of open coding it
Reviewed-by: Marek Behún
Re: [PATCH v2] leds: tlc591xx: fix leak of device node iterator
On Sat, 26 Sep 2020 02:51:17 +0200
Tobias Jordan wrote:
> In one of the error paths of the for_each_child_of_node loop in
> tlc591xx_probe, add missing call to of_node_put.
>
> Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
> managed led API")
>
> Signed-off-by: Tobias Jordan
> ---
> v2: rebased to Pavel's for-next branch
>
> drivers/leds/leds-tlc591xx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
> index f24271337bd8..5b9dfdf743ec 100644
> --- a/drivers/leds/leds-tlc591xx.c
> +++ b/drivers/leds/leds-tlc591xx.c
> @@ -205,10 +205,12 @@ tlc591xx_probe(struct i2c_client *client,
> led->ldev.max_brightness = TLC591XX_MAX_BRIGHTNESS;
> err = devm_led_classdev_register_ext(dev, &led->ldev,
>&init_data);
> - if (err < 0)
> + if (err < 0) {
> + of_node_put(child);
> return dev_err_probe(dev, err,
>"couldn't register LED %s\n",
> led->ldev.name);
> + }
> }
> return 0;
> }
Reviewed-by: Marek Behún
[PATCH net-next v1 1/3] dt-bindings: net: ethernet-phy: add description for PHY LEDs
Document binding for LEDs connected to and controlled by ethernet PHY chips. Signed-off-by: Marek Behún Cc: Rob Herring --- .../devicetree/bindings/net/ethernet-phy.yaml | 31 +++ 1 file changed, 31 insertions(+) diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index a9e547ac79051..11839265cc2f9 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -174,6 +174,37 @@ properties: PHY's that have configurable TX internal delays. If this property is present then the PHY applies the TX delay. +patternProperties: + "^led@[0-9a-f]+$": +type: object +description: + This node represents a LED device connected to the PHY chip. +$ref: /schemas/leds/common.yaml# + +properties: + reg: +maxItems: 1 + + enable-active-high: +description: + Polarity of LED is active high. If missing, assumed default is active low. +type: boolean + + led-open-drain: +description: + LED pin is open drain type. If missing, assumed false. +type: boolean + + linux,default-hw-mode: +description: + This parameter, if present, specifies the default HW triggering mode of the LED + when LED trigger is set to `phydev-hw-mode`. + Available values are specific per PHY chip and per LED. +$ref: /schemas/types.yaml#definitions/string + +required: + - reg + required: - reg -- 2.26.2
[PATCH net-next v1 3/3] net: phy: marvell: add support for LEDs controlled by Marvell PHYs
This patch adds support for controlling the LEDs connected to several
families of Marvell PHYs via the PHY HW LED trigger API. These families
are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can
be added.
This patch does not yet add support for compound LED modes. This could
be achieved via the LED multicolor framework.
Settings such as HW blink rate or pulse stretch duration are not yet
supported.
Signed-off-by: Marek Behún
---
drivers/net/phy/marvell.c | 309 +-
1 file changed, 307 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bb86ac0bd0920..e0293f309644a 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -148,6 +148,13 @@
#define MII_88E1510_PHY_LED_DEF0x1177
#define MII_88E1510_PHY_LED0_LINK_LED1_ACTIVE 0x1040
+#define MII_PHY_LED_POLARITY_CTRL 17
+#define MII_PHY_LED_TIMER_CTRL 18
+#define MII_PHY_LED45_CTRL 19
+
+#define MII_PHY_LED_CTRL_FORCE_ON 0x9
+#define MII_PHY_LED_CTRL_FORCE_OFF 0x8
+
#define MII_M1011_PHY_STATUS 0x11
#define MII_M1011_PHY_STATUS_1000 0x8000
#define MII_M1011_PHY_STATUS_100 0x4000
@@ -252,6 +259,8 @@
#define LPA_PAUSE_FIBER0x180
#define LPA_PAUSE_ASYM_FIBER 0x100
+#define MARVELL_PHY_MAX_LEDS 6
+
#define NB_FIBER_STATS 1
MODULE_DESCRIPTION("Marvell PHY driver");
@@ -280,6 +289,7 @@ struct marvell_priv {
u32 last;
u32 step;
s8 pair;
+ u16 legacy_led_config_mask;
};
static int marvell_read_page(struct phy_device *phydev)
@@ -662,8 +672,295 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
return err;
}
+#if IS_ENABLED(CONFIG_PHY_LEDS)
+
+enum {
+ COMMON = BIT(0),
+ L1V0_RECV = BIT(1),
+ L1V0_COPPER = BIT(2),
+ L1V5_100_FIBER = BIT(3),
+ L1V5_100_10 = BIT(4),
+ L2V2_INIT = BIT(5),
+ L2V2_PTP= BIT(6),
+ L2V2_DUPLEX = BIT(7),
+ L3V0_FIBER = BIT(8),
+ L3V0_LOS= BIT(9),
+ L3V5_TRANS = BIT(10),
+ L3V7_FIBER = BIT(11),
+ L3V7_DUPLEX = BIT(12),
+};
+
+struct marvell_led_mode_info {
+ const char *name;
+ s8 regval[MARVELL_PHY_MAX_LEDS];
+ u32 flags;
+};
+
+static const struct marvell_led_mode_info marvell_led_mode_info[] = {
+ { "link", { 0x0, -1, 0x0, -1, -1, -1, },
COMMON },
+ { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, },
COMMON },
+ { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1, -1, -1, -1, },
COMMON },
+ { "act",{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, },
COMMON },
+ { "blink-act", { 0x4, 0x4, 0x4, 0x4, 0x4, 0x4, },
COMMON },
+ { "tx", { 0x5, -1, 0x5, -1, 0x5, 0x5, },
COMMON },
+ { "tx", { -1, -1, -1, 0x5, -1, -1, },
L3V5_TRANS },
+ { "rx", { -1, -1, -1, -1, 0x0, 0x0, },
COMMON },
+ { "rx", { -1, 0x0, -1, -1, -1, -1, },
L1V0_RECV },
+ { "copper", { 0x6, -1, -1, -1, -1, -1, },
COMMON },
+ { "copper", { -1, 0x0, -1, -1, -1, -1, },
L1V0_COPPER },
+ { "1Gbps", { 0x7, -1, -1, -1, -1, -1, },
COMMON },
+ { "link/rx",{ -1, 0x2, -1, 0x2, 0x2, 0x2, },
COMMON },
+ { "100Mbps-fiber", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_FIBER },
+ { "100Mbps-10Mbps", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_10 },
+ { "1Gbps-100Mbps", { -1, 0x6, -1, -1, -1, -1, },
COMMON },
+ { "1Gbps-10Mbps", { -1, -1, 0x6, 0x6, -1, -1, },
COMMON },
+ { "100Mbps",{ -1, 0x7, -1, -1, -1, -1, },
COMMON },
+ { "10Mbps", { -1, -1, 0x7, -1, -1, -1, },
COMMON },
+ { "fiber", { -1, -1, -1, 0x0, -1, -1, },
L3V0_FIBER },
+ { "fiber", { -1, -1, -1, 0x7, -1, -1, },
L3V7_FIBER },
+ { "FullDuplex", { -1, -1, -1, 0x7, -1, -1, },
L3V7_DUPLEX },
+ { "FullDuplex", { -1, -1, -1, -1, 0x6, 0x6, },
COMMON },
+ { "FullDuplex/collision", { -1, -1, -1, -1, 0x7, 0x7, },
COMMON },
+ { "FullDuplex/collision", { -1, -1, 0x2, -1, -1, -1, },
L2
[PATCH net-next v1 0/3] Add support for LEDs on Marvell PHYs
Hi, after 4 RFC versions I am now sending these patches for real. The code applies on net-next. Changes since RFC v4: - added device-tree binding documentation - the OF code now checks for linux,default-hw-mode property so that default HW mode can be set in device tree (like linux,default-trigger) (this was suggested by Andrew) - the OF code also checks for enable-active-high and led-open-drain properties, and the marvell PHY driver now understands uses these settings when initializing the LEDs - the LED operations were moved to their own struct phy_device_led_ops - a new member was added into struct phy_device: phyindex. This is an incrementing integer, new for each registered phy_device. This is used for a simple naming scheme for the devicename part of a LED, as was suggested in a discussion by Andrew and Pavel. A PHY controlled LED now has a name in form: phy%i:color:function When a PHY is attached to a netdevice, userspace can control available PHY controlled LEDs via /sys/class/net//phydev/leds/ - legacy LED configuration in Marvell PHY driver (in function marvell_config_led) now writes only to registers which do not correspond to any registered LED Changes since RFC v3: - addressed some of Andrew's suggestions - phy_hw_led_mode.c renamed to phy_led.c - the DT reading code is now also generic, moved to phy_led.c and called from phy_probe - the function registering the phydev-hw-mode trigger is now called from phy_device.c function phy_init before registering genphy drivers - PHY LED functionality now depends on CONFIG_LEDS_TRIGGERS Changes since RFC v2: - to share code with other drivers which may want to also offer PHY HW control of LEDs some of the code was refactored and now resides in phy_hw_led_mode.c. This code is compiled in when config option LED_TRIGGER_PHY_HW is enabled. Drivers wanting to offer PHY HW control of LEDs should depend on this option. - the "hw-control" trigger is renamed to "phydev-hw-mode" and is registered by the code in phy_hw_led_mode.c - the "hw_control" sysfs file is renamed to "hw_mode" - struct phy_driver is extended by three methods to support PHY HW LED control - I renamed the various HW control modes offeret by Marvell PHYs to conform to other Linux mode names, for example the "1000/100/10/else" mode was renamed to "1Gbps/100Mbps/10Mbps", or "recv/else" was renamed to "rx" (this is the name of the mode in netdev trigger). Marek Behún (3): dt-bindings: net: ethernet-phy: add description for PHY LEDs net: phy: add API for LEDs controlled by ethernet PHY chips net: phy: marvell: add support for LEDs controlled by Marvell PHYs .../devicetree/bindings/net/ethernet-phy.yaml | 31 ++ drivers/net/phy/Kconfig | 4 + drivers/net/phy/Makefile | 1 + drivers/net/phy/marvell.c | 309 +- drivers/net/phy/phy_device.c | 28 +- drivers/net/phy/phy_led.c | 224 + include/linux/phy.h | 91 ++ 7 files changed, 679 insertions(+), 9 deletions(-) create mode 100644 drivers/net/phy/phy_led.c -- 2.26.2
[PATCH net-next v1 2/3] net: phy: add API for LEDs controlled by ethernet PHY chips
Many an ethernet PHY supports various HW control modes for LEDs
connected directly to the PHY chip.
This patch adds code for registering such LEDs when described in device
tree and also adds a new private LED trigger called phydev-hw-mode.
When this trigger is enabled for a LED, the various HW control modes
which are supported by the PHY for given LED cat be get/set via hw_mode
sysfs file.
A PHY driver wishing to utilize this API needs to implement all the
methods in the phy_device_led_ops structure.
Signed-off-by: Marek Behún
---
drivers/net/phy/Kconfig | 4 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy_device.c | 28 +++--
drivers/net/phy/phy_led.c| 224 +++
include/linux/phy.h | 91 ++
5 files changed, 341 insertions(+), 7 deletions(-)
create mode 100644 drivers/net/phy/phy_led.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 698bea312adc6..6ab8956c49b06 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -61,6 +61,10 @@ config SFP
depends on HWMON || HWMON=n
select MDIO_I2C
+config PHY_LEDS
+ bool
+ default y if LEDS_TRIGGERS
+
comment "MII PHY device drivers"
config AMD_PHY
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index a13e402074cf8..8a54fb30a729d 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -20,6 +20,7 @@ endif
obj-$(CONFIG_MDIO_DEVRES) += mdio_devres.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
+libphy-$(CONFIG_PHY_LEDS) += phy_led.o
obj-$(CONFIG_PHYLINK) += phylink.o
obj-$(CONFIG_PHYLIB) += libphy.o
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 8adfbad0a1e8f..8a28134841ec3 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -9,6 +9,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -892,6 +893,7 @@ EXPORT_SYMBOL(get_phy_device);
*/
int phy_device_register(struct phy_device *phydev)
{
+ static atomic_t phyindex;
int err;
err = mdiobus_register_device(&phydev->mdio);
@@ -908,6 +910,7 @@ int phy_device_register(struct phy_device *phydev)
goto out;
}
+ phydev->phyindex = atomic_inc_return(&phyindex) - 1;
err = device_add(&phydev->mdio.dev);
if (err) {
phydev_err(phydev, "failed to add\n");
@@ -2909,6 +2912,8 @@ static int phy_probe(struct device *dev)
phydev->supported);
}
+ of_phy_register_leds(phydev);
+
/* Set the state to READY by default */
phydev->state = PHY_READY;
@@ -3040,24 +3045,32 @@ static int __init phy_init(void)
{
int rc;
- rc = mdio_bus_init();
+ rc = phy_leds_init();
if (rc)
return rc;
+ rc = mdio_bus_init();
+ if (rc)
+ goto err_leds;
+
ethtool_set_ethtool_phy_ops(&phy_ethtool_phy_ops);
features_init();
rc = phy_driver_register(&genphy_c45_driver, THIS_MODULE);
if (rc)
- goto err_c45;
+ goto err_mdio;
rc = phy_driver_register(&genphy_driver, THIS_MODULE);
- if (rc) {
- phy_driver_unregister(&genphy_c45_driver);
-err_c45:
- mdio_bus_exit();
- }
+ if (rc)
+ goto err_c45;
+ return 0;
+err_c45:
+ phy_driver_unregister(&genphy_c45_driver);
+err_mdio:
+ mdio_bus_exit();
+err_leds:
+ phy_leds_exit();
return rc;
}
@@ -3067,6 +3080,7 @@ static void __exit phy_exit(void)
phy_driver_unregister(&genphy_driver);
mdio_bus_exit();
ethtool_set_ethtool_phy_ops(NULL);
+ phy_leds_exit();
}
subsys_initcall(phy_init);
diff --git a/drivers/net/phy/phy_led.c b/drivers/net/phy/phy_led.c
new file mode 100644
index 0..80d203b41c92e
--- /dev/null
+++ b/drivers/net/phy/phy_led.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* drivers/net/phy/phy_hw_led_mode.c
+ *
+ * PHY HW LED mode trigger
+ *
+ * Copyright (C) 2020 Marek Behun
+ */
+#include
+#include
+#include
+#include
+
+int phy_led_brightness_set(struct led_classdev *cdev, enum led_brightness
brightness)
+{
+ struct phy_device_led *led = led_cdev_to_phy_device_led(cdev);
+ struct phy_device *phydev = to_phy_device(cdev->dev->parent);
+ int ret;
+
+ mutex_lock(&phydev->lock);
+ ret = phydev->led_ops->led_brightness_set(phydev, led, brightness);
+ mutex_unlock(&phydev->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_led_brightness_set);
+
+static int of_phy_register_led(struct phy_device *phydev, struct device_node
*np)
+{
+
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Mon, 19 Oct 2020 10:35:12 +0200 Udo van den Heuvel wrote: > People, > > At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can > read that the LEDS code supposedly optimizes away when certain > conditions are met. > Especially the Realtek HDA driver *unconditionally* (as found in > 5.9.1) *wants* to enable LED functionality. > I.e.: if this blockade is lifted in the source tree then I can live > with the 'is optimized out' predictions, assuming that gcc (from > Fedora 32) can do this. > So the request is clear; we're almost there. > Please make it so that the compiler can do the 'optimize away' work > bij changing a tad in the Realtek HDA driver, along the lines of the > patch sent to me earlier or something even more beautiful. > > Thanks in advance and kind regards, > Udo Udo, The documentation says that LED trigger code optimises away, not LED core. But yes, something similar could maybe be done for the whole LED class... (maybe!) BTW, you are welcome to propose a patch as well, since it seems that nobody else is interested as much as you are in this :) Marek
Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
On Sun, 15 Nov 2020 03:26:01 +0100 Andreas Färber wrote: > Hi Russell, > > On 15.11.20 02:02, Russell King - ARM Linux admin wrote: > > On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote: > >> Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta: > >> Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX. > >> > >> In case a comphy is not provided, mvneta_validate()'s check > >> state->interface == PHY_INTERFACE_MODE_2500BASEX > >> could never be true (it would've returned with empty bitmask before), > >> so that 2500baseT_Full and 2500baseX_Full do net get added to the mask. > > > > This makes me nervous. It was intentional that if there is no comphy > > configured in DT for SoCs such as Armada 388, then there is no support > > to switch between 1G and 2.5G speed. Unfortunately, the configuration > > of the comphy is up to the board to do, not the SoC .dtsi, so we can't > > rely on there being a comphy on Armada 388 systems. > > Please note that the if clause at the beginning of the validate function > does not check for comphy at all. So even with comphy, if there is a > code path that attempts to validate state 2500BASEX, it is broken, too. > > Do you consider the modification of both ifs (validate and power_up) as > correct? Should they be split off from my main _NA change you discuss? > > > So, one of the side effects of this patch is it incorrectly opens up > > the possibility of allowing 2.5G support on Armada 388 without a comphy > > configured. > > > > We really need a better way to solve this; just relying on the lack of > > comphy and poking at a register that has no effect on Armada 388 to > > select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen > > doesn't sound like a good idea to me. > [snip] > > May I add that the comphy needs better documentation? > > Marek and I independently came up with <&comphy5 2> in the end, but the > DT binding doesn't explain what the index is supposed to be and how I > might figure it out. It cost me days of reading U-Boot and kernel > sources and playing around with values until I had the working one. > > Might be helpful to have a symbolic dt-bindings #define for this 2. > The gbe mux number is described in Armada 385 documentation. Yes, maybe we should add these defines somewhere, but certainly we should not declare ability of 2500baseX if comphy is not present and the interface is not configured to 2500baseX by default. I propose putting this just into the dt binding documentation. No need for macros IMO, especially since these muxes may be different on each SOC. Marek
Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy
On Sun, 15 Nov 2020 01:41:51 +0100
Andreas Färber wrote:
> - if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
> + if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX
> +|| state->interface == PHY_INTERFACE_MODE_NA) {
> phylink_set(mask, 2500baseT_Full);
> phylink_set(mask, 2500baseX_Full);
> }
No, this will cause, on systems without comphy described, phylink to
think that 2500baseX/T is possible. But without comphy how can it be
configured?
Marek
Re: [PATCH] clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9
Also, this is how A3720 WTMI code and ATF determines XTAL clock rate.
No reason for kernel to do it differently.
Reviewed-by: Marek Behún
On Fri, 6 Nov 2020 11:00:39 +0100
Pali Rohár wrote:
> From: Terry Zhou
>
> There is an error in the current code that the XTAL MODE
> pin was set to NB MPP1_31 which should be NB MPP1_9.
> The latch register of NB MPP1_9 has different offset of 0x8.
>
> Signed-off-by: Terry Zhou
> [pali: Fix pin name in commit message]
> Signed-off-by: Pali Rohár
> Fixes: 7ea8250406a6 ("clk: mvebu: Add the xtal clock for Armada 3700 SoC")
> Cc: sta...@vger.kernel.org
>
> ---
> This patch is present in Marvell SDK and also in Marvell's kernel fork:
> https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/80d4cec4cef8282e5ac3aaf98ce3e68fb299a134
>
> Konstantin Porotchkin wrote on Github that Gregory Clement was notified
> about this patch, but as this patch is still not in mainline kernel I'm
> sending it again for review.
>
> In original commit message (only in commit message, not code) was
> specified MPP9 pin on South Bridge, but correct is North Bridge.
> ---
> drivers/clk/mvebu/armada-37xx-xtal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mvebu/armada-37xx-xtal.c
> b/drivers/clk/mvebu/armada-37xx-xtal.c
> index e9e306d4e9af..41271351cf1f 100644
> --- a/drivers/clk/mvebu/armada-37xx-xtal.c
> +++ b/drivers/clk/mvebu/armada-37xx-xtal.c
> @@ -13,8 +13,8 @@
> #include
> #include
>
> -#define NB_GPIO1_LATCH 0xC
> -#define XTAL_MODEBIT(31)
> +#define NB_GPIO1_LATCH 0x8
> +#define XTAL_MODEBIT(9)
>
> static int armada_3700_xtal_clock_probe(struct platform_device *pdev)
> {
Re: [PATCH v30 01/16] leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros
On Mon, 13 Jul 2020 10:45:29 -0500 Dan Murphy wrote: > Fix the checkpatch warnings for the use of the file permission macros. > In converting the file permissions to the DEVICE_ATTR_XX macros the > call back function names needed to be updated within the code. > > This means that the lp55xx_ needed to be dropped in the name to keep > in harmony with the ABI documentation. > > Acked-by: Pavel Machek > Acked-by: Jacek Anaszewski > Signed-off-by: Dan Murphy > --- > drivers/leds/leds-lp55xx-common.c | 22 ++ > 1 file changed, 10 insertions(+), 12 deletions(-) > Reviewed-by: Marek Behún
Re: [PATCH v30 02/16] leds: lp5523: Fix various formatting issues in the code
On Mon, 13 Jul 2020 10:45:30 -0500 Dan Murphy wrote: > Fix checkpatch errors and warnings for the LP5523.c device > driver. > > Acked-by: Pavel Machek > Acked-by: Jacek Anaszewski > Signed-off-by: Dan Murphy > --- > drivers/leds/leds-lp5523.c | 19 ++- > 1 file changed, 10 insertions(+), 9 deletions(-) Reviewed-by: Marek Behún
Re: [PATCH v30 03/16] dt: bindings: Add multicolor class dt bindings documention
On Mon, 13 Jul 2020 10:45:31 -0500 Dan Murphy wrote: > Add DT bindings for the LEDs multicolor class framework. > Add multicolor ID to the color ID list for device tree bindings. > > CC: Rob Herring > Reviewed-by: Rob Herring > Acked-by: Pavel Machek > Acked-by: Jacek Anaszewski > Signed-off-by: Dan Murphy > --- > .../bindings/leds/leds-class-multicolor.yaml | 37 > +++ include/dt-bindings/leds/common.h | > 3 +- 2 files changed, 39 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml Reviewed-by: Marek Behún
Re: [PATCH v30 05/16] leds: multicolor: Introduce a multicolor class definition
On Mon, 13 Jul 2020 10:45:33 -0500 Dan Murphy wrote: > Introduce a multicolor class that groups colored LEDs > within a LED node. > > The multi color class groups monochrome LEDs and allows controlling > two aspects of the final combined color: hue and lightness. The > former is controlled via the intensity file and the latter is > controlled via brightness file. > > Acked-by: Jacek Anaszewski > Signed-off-by: Dan Murphy > --- > .../ABI/testing/sysfs-class-led-multicolor| 35 +++ > Documentation/leds/index.rst | 1 + > Documentation/leds/leds-class-multicolor.rst | 86 > drivers/leds/Kconfig | 10 + > drivers/leds/Makefile | 1 + > drivers/leds/led-class-multicolor.c | 204 > ++ include/linux/led-class-multicolor.h | > 121 +++ 7 files changed, 458 insertions(+) > create mode 100644 > Documentation/ABI/testing/sysfs-class-led-multicolor create mode > 100644 Documentation/leds/leds-class-multicolor.rst create mode > 100644 drivers/leds/led-class-multicolor.c create mode 100644 > include/linux/led-class-multicolor.h Reviewed-by: Marek Behún
Re: [PATCH v30 04/16] leds: Add multicolor ID to the color ID list
On Mon, 13 Jul 2020 10:45:32 -0500 Dan Murphy wrote: > Add a new color ID that is declared as MULTICOLOR as with the > multicolor framework declaring a definitive color is not accurate > as the node can contain multiple colors. > > Signed-off-by: Dan Murphy > --- > drivers/leds/led-core.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Marek Behún
[PATCH 4/5] PCI: aardvark: Implement driver 'remove' function and allow to build it as module
From: Pali Rohár
Providing driver's 'remove' function allows kernel to bind and unbind devices
from aardvark driver. It also allows to build aardvark driver as a module.
Compiling aardvark as a module simplifies development and debugging of
this driver as it can be reloaded at runtime without the need to reboot
to new kernel.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/controller/Kconfig| 2 +-
drivers/pci/controller/pci-aardvark.c | 25 ++---
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index adddf21fa381..f9da5ff2c517 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -12,7 +12,7 @@ config PCI_MVEBU
select PCI_BRIDGE_EMUL
config PCI_AARDVARK
- bool "Aardvark PCIe controller"
+ tristate "Aardvark PCIe controller"
depends on (ARCH_MVEBU && ARM64) || COMPILE_TEST
depends on OF
depends on PCI_MSI_IRQ_DOMAIN
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index d5f58684d962..0a5aa6d77f5d 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1114,6 +1115,7 @@ static int advk_pcie_probe(struct platform_device *pdev)
pcie = pci_host_bridge_priv(bridge);
pcie->pdev = pdev;
+ platform_set_drvdata(pdev, pcie);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pcie->base = devm_ioremap_resource(dev, res);
@@ -1204,18 +1206,35 @@ static int advk_pcie_probe(struct platform_device *pdev)
return 0;
}
+static int advk_pcie_remove(struct platform_device *pdev)
+{
+ struct advk_pcie *pcie = platform_get_drvdata(pdev);
+ struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
+
+ pci_stop_root_bus(bridge->bus);
+ pci_remove_root_bus(bridge->bus);
+
+ advk_pcie_remove_msi_irq_domain(pcie);
+ advk_pcie_remove_irq_domain(pcie);
+
+ return 0;
+}
+
static const struct of_device_id advk_pcie_of_match_table[] = {
{ .compatible = "marvell,armada-3700-pcie", },
{},
};
+MODULE_DEVICE_TABLE(of, advk_pcie_of_match_table);
static struct platform_driver advk_pcie_driver = {
.driver = {
.name = "advk-pcie",
.of_match_table = advk_pcie_of_match_table,
- /* Driver unloading/unbinding currently not supported */
- .suppress_bind_attrs = true,
},
.probe = advk_pcie_probe,
+ .remove = advk_pcie_remove,
};
-builtin_platform_driver(advk_pcie_driver);
+module_platform_driver(advk_pcie_driver);
+
+MODULE_DESCRIPTION("Aardvark PCIe controller");
+MODULE_LICENSE("GPL v2");
--
2.26.2
[PATCH 1/5] PCI: aardvark: Fix compilation on s390
From: Pali Rohár
Include linux/gpio/consumer.h instead of linux/gpio.h, as is said in the
latter file.
This was reported by kernel test bot when compiling for s390.
drivers/pci/controller/pci-aardvark.c:350:2: error: implicit declaration of
function 'gpiod_set_value_cansleep' [-Werror,-Wimplicit-function-declaration]
drivers/pci/controller/pci-aardvark.c:1074:21: error: implicit declaration of
function 'devm_gpiod_get_from_of_node' [-Werror,-Wimplicit-function-declaration]
drivers/pci/controller/pci-aardvark.c:1076:14: error: use of undeclared
identifier 'GPIOD_OUT_LOW'
Link: https://lore.kernel.org/r/20200628.lxtenqfl%25...@intel.com
Reported-by: kernel test robot
Fixes: 5169a9851da ("PCI: aardvark: Issue PERST via GPIO")
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/controller/pci-aardvark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 90ff291c24f0..8caa80b19cf8 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -9,7 +9,7 @@
*/
#include
-#include
+#include
#include
#include
#include
--
2.26.2
[PATCH 5/5] PCI: aardvark: Move PCIe reset card code to advk_pcie_train_link()
From: Pali Rohár
Move code which belongs to link training (delays and resets) into
advk_pcie_train_link() function, so everything related to link training,
including timings is at one place.
After experiments it can be observed that link training in aardvark
hardware is very sensitive to timings and delays, so it is a good idea to
have this code at the same place as link training calls.
This patch does not change behavior of aardvark initialization.
Signed-off-by: Pali Rohár
Tested-by: Marek Behún
---
drivers/pci/controller/pci-aardvark.c | 64 ++-
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 0a5aa6d77f5d..ab39b01474e8 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -253,6 +253,25 @@ static void advk_pcie_wait_for_retrain(struct advk_pcie
*pcie)
}
}
+static void advk_pcie_issue_perst(struct advk_pcie *pcie)
+{
+ u32 reg;
+
+ if (!pcie->reset_gpio)
+ return;
+
+ /* PERST does not work for some cards when link training is enabled */
+ reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
+ reg &= ~LINK_TRAINING_EN;
+ advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
+
+ /* 10ms delay is needed for some cards */
+ dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n");
+ gpiod_set_value_cansleep(pcie->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(pcie->reset_gpio, 0);
+}
+
static int advk_pcie_train_at_gen(struct advk_pcie *pcie, int gen)
{
int ret, neg_gen;
@@ -300,6 +319,21 @@ static void advk_pcie_train_link(struct advk_pcie *pcie)
struct device *dev = &pcie->pdev->dev;
int neg_gen = -1, gen;
+ /*
+* Reset PCIe card via PERST# signal. Some cards are not detected
+* during link training when they are in some non-initial state.
+*/
+ advk_pcie_issue_perst(pcie);
+
+ /*
+* PERST# signal could have been asserted by pinctrl subsystem before
+* probe() callback has been called or issued explicitly by reset gpio
+* function advk_pcie_issue_perst(), making the endpoint going into
+* fundamental reset. As required by PCI Express spec a delay for at
+* least 100ms after such a reset before link training is needed.
+*/
+ msleep(PCI_PM_D3COLD_WAIT);
+
/*
* Try link training at link gen specified by device tree property
* 'max-link-speed'. If this fails, iteratively train at lower gen.
@@ -332,31 +366,10 @@ static void advk_pcie_train_link(struct advk_pcie *pcie)
dev_err(dev, "link never came up\n");
}
-static void advk_pcie_issue_perst(struct advk_pcie *pcie)
-{
- u32 reg;
-
- if (!pcie->reset_gpio)
- return;
-
- /* PERST does not work for some cards when link training is enabled */
- reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
- reg &= ~LINK_TRAINING_EN;
- advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
-
- /* 10ms delay is needed for some cards */
- dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n");
- gpiod_set_value_cansleep(pcie->reset_gpio, 1);
- usleep_range(1, 11000);
- gpiod_set_value_cansleep(pcie->reset_gpio, 0);
-}
-
static void advk_pcie_setup_hw(struct advk_pcie *pcie)
{
u32 reg;
- advk_pcie_issue_perst(pcie);
-
/* Enable TX */
reg = advk_readl(pcie, PCIE_CORE_REF_CLK_REG);
reg |= PCIE_CORE_REF_CLK_TX_ENABLE;
@@ -433,15 +446,6 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
reg |= PIO_CTRL_ADDR_WIN_DISABLE;
advk_writel(pcie, reg, PIO_CTRL);
- /*
-* PERST# signal could have been asserted by pinctrl subsystem before
-* probe() callback has been called or issued explicitly by reset gpio
-* function advk_pcie_issue_perst(), making the endpoint going into
-* fundamental reset. As required by PCI Express spec a delay for at
-* least 100ms after such a reset before link training is needed.
-*/
- msleep(PCI_PM_D3COLD_WAIT);
-
advk_pcie_train_link(pcie);
/*
--
2.26.2
[PATCH 3/5] PCI: pci-bridge-emul: Export API functions
From: Pali Rohár It allows kernel modules which are not compiled into kernel image to use pci-bridge-emul API functions. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci-bridge-emul.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c index ccf26d12ec61..139869d50eb2 100644 --- a/drivers/pci/pci-bridge-emul.c +++ b/drivers/pci/pci-bridge-emul.c @@ -294,6 +294,7 @@ int pci_bridge_emul_init(struct pci_bridge_emul *bridge, return 0; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_init); /* * Cleanup a pci_bridge_emul structure that was previously initialized @@ -305,6 +306,7 @@ void pci_bridge_emul_cleanup(struct pci_bridge_emul *bridge) kfree(bridge->pcie_cap_regs_behavior); kfree(bridge->pci_regs_behavior); } +EXPORT_SYMBOL_GPL(pci_bridge_emul_cleanup); /* * Should be called by the PCI controller driver when reading the PCI @@ -366,6 +368,7 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where, return PCIBIOS_SUCCESSFUL; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_conf_read); /* * Should be called by the PCI controller driver when writing the PCI @@ -430,3 +433,4 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where, return PCIBIOS_SUCCESSFUL; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_conf_write); -- 2.26.2
[PATCH 2/5] PCI: aardvark: Check for errors from pci_bridge_emul_init() call
From: Pali Rohár
Function pci_bridge_emul_init() may fail so correctly check for errors.
Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config
space")
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/controller/pci-aardvark.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 8caa80b19cf8..d5f58684d962 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -608,7 +608,7 @@ static struct pci_bridge_emul_ops advk_pci_bridge_emul_ops
= {
* Initialize the configuration space of the PCI-to-PCI bridge
* associated with the given PCIe interface.
*/
-static void advk_sw_pci_bridge_init(struct advk_pcie *pcie)
+static int advk_sw_pci_bridge_init(struct advk_pcie *pcie)
{
struct pci_bridge_emul *bridge = &pcie->bridge;
@@ -634,8 +634,7 @@ static void advk_sw_pci_bridge_init(struct advk_pcie *pcie)
bridge->data = pcie;
bridge->ops = &advk_pci_bridge_emul_ops;
- pci_bridge_emul_init(bridge, 0);
-
+ return pci_bridge_emul_init(bridge, 0);
}
static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
@@ -1169,7 +1168,11 @@ static int advk_pcie_probe(struct platform_device *pdev)
advk_pcie_setup_hw(pcie);
- advk_sw_pci_bridge_init(pcie);
+ ret = advk_sw_pci_bridge_init(pcie);
+ if (ret) {
+ dev_err(dev, "Failed to register emulated root PCI bridge\n");
+ return ret;
+ }
ret = advk_pcie_init_irq_domain(pcie);
if (ret) {
--
2.26.2
[PATCH 0/5] PCIe aardvark controller improvements
Hi, we have some more improvements for PCIe aardvark controller (Armada 3720 SOC - EspressoBIN and Turris MOX). The main improvement is that with these patches the driver can be compiled as a module, and can be reloaded at runtime. This series applies on top of Linus' master branch. Marek & Pali Pali Rohár (5): PCI: aardvark: Fix compilation on s390 PCI: aardvark: Check for errors from pci_bridge_emul_init() call PCI: pci-bridge-emul: Export API functions PCI: aardvark: Implement driver 'remove' function and allow to build it as module PCI: aardvark: Move PCIe reset card code to advk_pcie_train_link() drivers/pci/controller/Kconfig| 2 +- drivers/pci/controller/pci-aardvark.c | 102 -- drivers/pci/pci-bridge-emul.c | 4 + 3 files changed, 69 insertions(+), 39 deletions(-) -- 2.26.2
Re: [PATCH RFC] leds: Add support for per-LED device triggers
On Sat, 11 Jul 2020 12:04:09 +0200
Pavel Machek wrote:
> What about this? Should address Marek's concerns about resource use...
>
> Best regards,
> Pavel
>
...
> @@ -280,7 +291,8 @@ int led_trigger_register(struct led_trigger *trig)
> down_write(&triggers_list_lock);
> /* Make sure the trigger's name isn't already in use */
> list_for_each_entry(_trig, &trigger_list, next_trig) {
> - if (!strcmp(_trig->name, trig->name)) {
> + if (!strcmp(_trig->name, trig->name) &&
> + (!_trig->private_led || _trig->private_led ==
> trig->private_led)) { up_write(&triggers_list_lock);
> return -EEXIST;
> }
Hi Pavel,
Your proposal does not add private_led member to struct led_trigger. I
think you forgot to change this from Ondrej's proposal.
This should instead check:
the names are same and both trigger have the same type (either none
or same). In that case return -EEXIST.
Also a couple of lines below there is code for enabling this trigger
for LEDs that have it set as default trigger. There should also be a
check whether the trigger is relevant.
In the linux/leds.h header the trigger_type in led_classdev should be
inside the CONFIG_LEDS_TRIGGERS block.
I will send new version with an example usage for a Marvell PHY driver.
Marek
Re: [PATCH RFC] leds: Add support for per-LED device triggers
On Wed, 15 Jul 2020 19:07:27 +0200 Marek Behún wrote: > This should instead check: > the names are same and both trigger have the same type (either none > or same). In that case return -EEXIST. My bad, this is of course wrong. -EEXIST should be returned if the names are same and triggers have same type or one of them has no type.
Re: [PATCH v30 04/16] leds: Add multicolor ID to the color ID list
On Wed, 15 Jul 2020 19:36:10 +0200 Pavel Machek wrote: > Thanks for patches, thanks for reviews, 1-4 applied. > Pavel The most important one is 5th, though :D
[PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW
Many PHYs support various HW control modes for LEDs connected directly
to them.
This adds code for registering such LEDs when described in device tree
and also adds a new private LED trigger called phydev-hw-mode. When
this trigger is enabled for a LED, the various HW control modes which
the PHY supports for given LED can be get/set via hw_mode sysfs file.
A PHY driver wishing to utilize this API needs to implement these
methods:
- led_brightness_set for software brightness changing
- led_iter_hw_mode, led_set_hw_mode and led_get_hw_mode for
getting/setting HW control mode
- led_init if the drivers wants phy-core to register the LEDs from
device tree
Signed-off-by: Marek Behún
---
drivers/net/phy/Kconfig | 4 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy_device.c | 25 +++--
drivers/net/phy/phy_led.c| 176 +++
include/linux/phy.h | 51 ++
5 files changed, 250 insertions(+), 7 deletions(-)
create mode 100644 drivers/net/phy/phy_led.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index dd20c2c27c2f..8972d2de25f6 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -283,6 +283,10 @@ config LED_TRIGGER_PHY
Mbps OR Gbps OR link
for any speed known to the PHY.
+config PHY_LEDS
+ bool
+ default y if LEDS_TRIGGERS
+
comment "MII PHY device drivers"
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index d84bab489a53..ef3c83759f93 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -20,6 +20,7 @@ endif
obj-$(CONFIG_MDIO_DEVRES) += mdio_devres.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
+libphy-$(CONFIG_PHY_LEDS) += phy_led.o
obj-$(CONFIG_PHYLINK) += phylink.o
obj-$(CONFIG_PHYLIB) += libphy.o
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1b9523595839..9a1e9da30f71 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2909,6 +2909,8 @@ static int phy_probe(struct device *dev)
phydev->supported);
}
+ of_phy_register_leds(phydev);
+
/* Set the state to READY by default */
phydev->state = PHY_READY;
@@ -3040,24 +3042,32 @@ static int __init phy_init(void)
{
int rc;
- rc = mdio_bus_init();
+ rc = phy_leds_init();
if (rc)
return rc;
+ rc = mdio_bus_init();
+ if (rc)
+ goto err_leds;
+
ethtool_set_ethtool_phy_ops(&phy_ethtool_phy_ops);
features_init();
rc = phy_driver_register(&genphy_c45_driver, THIS_MODULE);
if (rc)
- goto err_c45;
+ goto err_mdio;
rc = phy_driver_register(&genphy_driver, THIS_MODULE);
- if (rc) {
- phy_driver_unregister(&genphy_c45_driver);
-err_c45:
- mdio_bus_exit();
- }
+ if (rc)
+ goto err_c45;
+ return 0;
+err_c45:
+ phy_driver_unregister(&genphy_c45_driver);
+err_mdio:
+ mdio_bus_exit();
+err_leds:
+ phy_leds_exit();
return rc;
}
@@ -3067,6 +3077,7 @@ static void __exit phy_exit(void)
phy_driver_unregister(&genphy_driver);
mdio_bus_exit();
ethtool_set_ethtool_phy_ops(NULL);
+ phy_leds_exit();
}
subsys_initcall(phy_init);
diff --git a/drivers/net/phy/phy_led.c b/drivers/net/phy/phy_led.c
new file mode 100644
index ..85f67f39594f
--- /dev/null
+++ b/drivers/net/phy/phy_led.c
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * drivers/net/phy/phy_hw_led_mode.c
+ *
+ * PHY HW LED mode trigger
+ *
+ * Copyright (C) 2020 Marek Behun
+ */
+#include
+#include
+#include
+#include
+
+int phy_led_brightness_set(struct led_classdev *cdev, enum led_brightness
brightness)
+{
+ struct phy_device_led *led = led_cdev_to_phy_device_led(cdev);
+ struct phy_device *phydev = to_phy_device(cdev->dev->parent);
+ int ret;
+
+ mutex_lock(&phydev->lock);
+ ret = phydev->drv->led_brightness_set(phydev, led, brightness);
+ mutex_unlock(&phydev->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(phy_led_brightness_set);
+
+static int of_phy_register_led(struct phy_device *phydev, struct device_node
*np)
+{
+ struct led_init_data init_data = {};
+ struct phy_device_led *led;
+ u32 reg;
+ int ret;
+
+ ret = of_property_read_u32(np, "reg", ®);
+ if (ret < 0)
+ return ret;
+
+ led = devm_kzalloc(&phydev->mdio.dev, sizeof(struct phy_device_led),
GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led->cdev.brightness_set_blocking = phy_led_brightness_set;
+ led->cdev.trigger_type = &phy_hw_led_
[PATCH RFC leds + net-next v4 2/2] net: phy: marvell: add support for PHY LEDs via LED class
This patch adds support for controlling the LEDs connected to several
families of Marvell PHYs via the PHY HW LED trigger API. These families
are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can
be added.
This patch does not yet add support for compound LED modes. This could
be achieved via the LED multicolor framework (which is not yet in
upstream).
Settings such as HW blink rate or pulse stretch duration are not yet
supported, nor are LED polarity settings.
Signed-off-by: Marek Behún
---
drivers/net/phy/marvell.c | 287 ++
1 file changed, 287 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bb86ac0bd092..55882ce24e67 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -148,6 +148,11 @@
#define MII_88E1510_PHY_LED_DEF0x1177
#define MII_88E1510_PHY_LED0_LINK_LED1_ACTIVE 0x1040
+#define MII_PHY_LED45_CTRL 19
+
+#define MII_PHY_LED_CTRL_FORCE_ON 0x9
+#define MII_PHY_LED_CTRL_FORCE_OFF 0x8
+
#define MII_M1011_PHY_STATUS 0x11
#define MII_M1011_PHY_STATUS_1000 0x8000
#define MII_M1011_PHY_STATUS_100 0x4000
@@ -252,6 +257,8 @@
#define LPA_PAUSE_FIBER0x180
#define LPA_PAUSE_ASYM_FIBER 0x100
+#define MARVELL_PHY_MAX_LEDS 6
+
#define NB_FIBER_STATS 1
MODULE_DESCRIPTION("Marvell PHY driver");
@@ -662,6 +669,244 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
return err;
}
+#if IS_ENABLED(CONFIG_PHY_LEDS)
+
+enum {
+ COMMON = BIT(0),
+ L1V0_RECV = BIT(1),
+ L1V0_COPPER = BIT(2),
+ L1V5_100_FIBER = BIT(3),
+ L1V5_100_10 = BIT(4),
+ L2V2_INIT = BIT(5),
+ L2V2_PTP= BIT(6),
+ L2V2_DUPLEX = BIT(7),
+ L3V0_FIBER = BIT(8),
+ L3V0_LOS= BIT(9),
+ L3V5_TRANS = BIT(10),
+ L3V7_FIBER = BIT(11),
+ L3V7_DUPLEX = BIT(12),
+};
+
+struct marvell_led_mode_info {
+ const char *name;
+ s8 regval[MARVELL_PHY_MAX_LEDS];
+ u32 flags;
+};
+
+static const struct marvell_led_mode_info marvell_led_mode_info[] = {
+ { "link", { 0x0, -1, 0x0, -1, -1, -1, },
COMMON },
+ { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, },
COMMON },
+ { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1, -1, -1, -1, },
COMMON },
+ { "act",{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, },
COMMON },
+ { "blink-act", { 0x4, 0x4, 0x4, 0x4, 0x4, 0x4, },
COMMON },
+ { "tx", { 0x5, -1, 0x5, -1, 0x5, 0x5, },
COMMON },
+ { "tx", { -1, -1, -1, 0x5, -1, -1, },
L3V5_TRANS },
+ { "rx", { -1, -1, -1, -1, 0x0, 0x0, },
COMMON },
+ { "rx", { -1, 0x0, -1, -1, -1, -1, },
L1V0_RECV },
+ { "copper", { 0x6, -1, -1, -1, -1, -1, },
COMMON },
+ { "copper", { -1, 0x0, -1, -1, -1, -1, },
L1V0_COPPER },
+ { "1Gbps", { 0x7, -1, -1, -1, -1, -1, },
COMMON },
+ { "link/rx",{ -1, 0x2, -1, 0x2, 0x2, 0x2, },
COMMON },
+ { "100Mbps-fiber", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_FIBER },
+ { "100Mbps-10Mbps", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_10 },
+ { "1Gbps-100Mbps", { -1, 0x6, -1, -1, -1, -1, },
COMMON },
+ { "1Gbps-10Mbps", { -1, -1, 0x6, 0x6, -1, -1, },
COMMON },
+ { "100Mbps",{ -1, 0x7, -1, -1, -1, -1, },
COMMON },
+ { "10Mbps", { -1, -1, 0x7, -1, -1, -1, },
COMMON },
+ { "fiber", { -1, -1, -1, 0x0, -1, -1, },
L3V0_FIBER },
+ { "fiber", { -1, -1, -1, 0x7, -1, -1, },
L3V7_FIBER },
+ { "FullDuplex", { -1, -1, -1, 0x7, -1, -1, },
L3V7_DUPLEX },
+ { "FullDuplex", { -1, -1, -1, -1, 0x6, 0x6, },
COMMON },
+ { "FullDuplex/collision", { -1, -1, -1, -1, 0x7, 0x7, },
COMMON },
+ { "FullDuplex/collision", { -1, -1, 0x2, -1, -1, -1, },
L2V2_DUPLEX },
+ { "ptp",{ -1, -1, 0x2, -1, -1, -1, },
L2V2_PTP },
+ { "init", { -1, -1, 0x2, -1, -1, -1, },
L2V2_INIT },
+ { &quo
[PATCH RFC leds + net-next v4 0/2] Add support for LEDs on Marvell PHYs
Hi, this is v4 of my RFC adding support for LEDs connected to Marvell PHYs. Please note that if you want to test this, you still need to first apply the patch adding the LED private triggers support from Pavel's tree. https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next&id=93690cdf3060c61dfce813121d0bfc055e7fa30d What I still don't like about this is that the LEDs created by the code don't properly support device names. LEDs should have name in format "device:color:function", for example "eth0:green:activity". The code currently looks for attached netdev for a given PHY, but at the time this happens there is no netdev attached, so the LEDs gets names without the device part (ie ":green:activity"). This can be addressed in next version by renaming the LED when a netdev is attached to the PHY, but first a API for LED device renaming needs to be proposed. I am going to try to do that. This would also solve the same problem when userspace renames an interface. And no, I don't want phydev name there. Changes since v3: - addressed some of Andrew's suggestions - phy_hw_led_mode.c renamed to phy_led.c - the DT reading code is now also generic, moved to phy_led.c and called from phy_probe - the function registering the phydev-hw-mode trigger is now called from phy_device.c function phy_init before registering genphy drivers - PHY LED functionality now depends on CONFIG_LEDS_TRIGGERS Changes since v2: - to share code with other drivers which may want to also offer PHY HW control of LEDs some of the code was refactored and now resides in phy_hw_led_mode.c. This code is compiled in when config option LED_TRIGGER_PHY_HW is enabled. Drivers wanting to offer PHY HW control of LEDs should depend on this option. - the "hw-control" trigger is renamed to "phydev-hw-mode" and is registered by the code in phy_hw_led_mode.c - the "hw_control" sysfs file is renamed to "hw_mode" - struct phy_driver is extended by three methods to support PHY HW LED control - I renamed the various HW control modes offeret by Marvell PHYs to conform to other Linux mode names, for example the "1000/100/10/else" mode was renamed to "1Gbps/100Mbps/10Mbps", or "recv/else" was renamed to "rx" (this is the name of the mode in netdev trigger). Marek Marek Behún (2): net: phy: add API for LEDs controlled by PHY HW net: phy: marvell: add support for PHY LEDs via LED class drivers/net/phy/Kconfig | 4 + drivers/net/phy/Makefile | 1 + drivers/net/phy/marvell.c| 287 +++ drivers/net/phy/phy_device.c | 25 ++- drivers/net/phy/phy_led.c| 176 + include/linux/phy.h | 51 +++ 6 files changed, 537 insertions(+), 7 deletions(-) create mode 100644 drivers/net/phy/phy_led.c -- 2.26.2
Re: [PATCH RFC leds + net-next v4 1/2] net: phy: add API for LEDs controlled by PHY HW
On Tue, 28 Jul 2020 17:05:29 +0200
Marek Behún wrote:
> @@ -736,6 +777,16 @@ struct phy_driver {
> int (*set_loopback)(struct phy_device *dev, bool enable);
> int (*get_sqi)(struct phy_device *dev);
> int (*get_sqi_max)(struct phy_device *dev);
> +
> + /* PHY LED support */
> + int (*led_init)(struct phy_device *dev, struct
> phy_device_led *led);
> + int (*led_brightness_set)(struct phy_device *dev, struct
> phy_device_led *led,
> + enum led_brightness brightness);
> + const char *(*led_iter_hw_mode)(struct phy_device *dev,
> struct phy_device_led *led,
> + void ** iter);
> + int (*led_set_hw_mode)(struct phy_device *dev, struct
> phy_device_led *led,
> +const char *mode);
> + const char *(*led_get_hw_mode)(struct phy_device *dev,
> struct phy_device_led *led); };
> #define to_phy_driver(d)
> container_of(to_mdio_common_driver(d),\ struct
> phy_driver, mdiodrv)
The problem here is that the same code will have to be added to DSA
switch ops structure, which is not OK.
I wanted to put this into struct mdio_driver_common, so that all mdio
drivers would be able to have HW LEDs connected. But then I remembered
that not all DSA drivers are connected via MDIO, some are via SPI.
So maybe this could instead become part of LED API, instead of phydev
API. Structure
struct hw_controlled_led
and
struct hw_controlled_led_ops
could be offered by the LED API, which would also register the needed
trigger.
struct phydev, struct dsa_switch and other could then just contain
pointer to struct hw_controlled_led_ops...
Marek
Re: [PATCH RFC leds + net-next 0/3] Add support for LEDs on Marvell PHYs
On Thu, 16 Jul 2020 20:56:47 +0200 Andrew Lunn wrote: > On Thu, Jul 16, 2020 at 07:17:27PM +0200, Marek Behún wrote: > > Hello, > > > > this RFC series should apply on both net-next/master and Pavel's > > linux-leds/for-master tree. > > > > This adds support for LED's connected to some Marvell PHYs. > > > > LEDs are specified via device-tree. Example: > > Hi Marek > > I've been playing with something similar, off and on, mostly off. > > Take a look at > > https://github.com/lunn/linux v5.4-rc6-hw-led-triggers > > The binding i have is pretty much the same, since we are both > following the common LED binding. I see no problems with this. > > > This is achieved by extending the LED trigger API with LED-private > > triggers. The proposal for this is based on work by Ondrej and > > Pavel. > > So what i did here was allow triggers to be registered against a > specific LED. The /sys/class/leds//trigger lists both the generic > triggers and the triggers for this specific LED. Phylib can then > register a trigger for each blink reason that specific LED can > perform. Which does result in a lot of triggers. Especially when you > start talking about a 10 port switch each with 2 LEDs. > > I still have some open issues... > Hi Andrew, Pavel Machek has applied support for LED private triggers yesterday, see https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next&id=93690cdf3060c61dfce813121d0bfc055e7fa30d The way this is handled has this issue - it results in a lot of triggers, if we want each possible control to have its own trigger in the sysfs trigger file. But as Ondrej pointed out, we can just register one "hw-control" device trigger, and have its activation create another file/files via which the user can select which type of HW control he wants to activate. Something similar is done in netdev trigger. I don't like it much, but this is what can be done if we want to avoid having lots of triggers registered. > 1) Polarity. It would be nice to be able to configure the polarity of > the LED in the bindings. Yes, and also the DUAL mode and everything else. > 2) PHY LEDs which are not actually part of the PHY. Most of the > Marvell Ethernet switches have inbuilt PHYs, which are driven by the > Marvell PHY driver. The Marvell PHY driver has no idea the PHY is > inside a switch, it is just a PHY. However, the LEDs are not > controlled via PHY registers, but Switch registers. So the switch > driver is going to end up controlling these LEDs. It would be good to > be able to share as much code as possible, keep the naming consistent, > and keep the user API the same. I know about this - in fact I want this solved for Turris MOX, which has one 1518 PHY and can have up to three switches connected - I want every LED to be configurable by userspace. The internal PHY of the switch can be identified in the marvell phy driver not to register any LEDs. Then the switch LEDs can be controlled by the switch driver. I don't think we are able to share much of the code, since the access to these registers is different from the LED registers in the PHY, and register values are also different. The only think which could be shared are names of the trigger, I think. But I will look into this and prepare a patch series that will share as much code as is reasonable. > 3) Some PHYs cannot control the LEDs independently. Or they have modes > which configure two or more LEDs. The Marvell PHYs are like > this. There are something like ~10 blink modes which are > independent. And then there are 4 modes which control multiple LEDs. > There is no simple way to support this with Linux LEDs which assume > the LEDs are fully independent. I suspect we simply cannot support > these combined modes. I know about these modes, I have func specs for several differnet Marvell PHYs and switches opened and have read about the LED systems. I intend to do this so that all corner cases are considere. > As a PHY maintainer, i would like to see a solution which makes use of > Linux LEDs. I don't really care who's code it is, and feel free to > borrow my code, or ideas, or ignore it. > > Andrew Wait a few days and I shall send another proposal. Marek
[PATCH RFC leds + net-next v2 0/1] Add support for LEDs on Marvell PHYs
Hi, this is v2 of my RFC adding support for LEDs connected to Marvell PHYs. The LED subsystem patches are not contained: - the patch adding support for LED private triggers is already accepted in Pavel Machek's for-next tree. If you want to try this patch on top of net-next, please also apply https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next&id=93690cdf3060c61dfce813121d0bfc055e7fa30d - the other led-trigger patch is not needed in this version of the RFC The main difference from v1 is that only one trigger, named "hw-control", is added to the /sys/class/leds//trigger file. When this trigger is activated, another file called "hw_control" is created in the /sys/class/leds// directory. This file lists available HW control modes for this LED in the same way the trigger file does for triggers. Example: # cd /sys/class/leds/eth0\:green\:link/ # cat trigger [none] hw-control timer oneshot heartbeat ... # echo hw-control >trigger # cat trigger none [hw-control] timer oneshot heartbeat ... # cat hw_control link/nolink link/act/nolink 1000/100/10/nolink act/noact blink-act/noact transmit/notransmit copperlink/else [1000/else] force-hi-z force-blink # echo 1000/100/10/nolink >hw_control # cat hw_control link/nolink link/act/nolink [1000/100/10/nolink] act/noact blink-act/noact transmit/notransmit copperlink/else 1000/else force-hi-z force-blink The benefit here is that only one trigger is registered via LED API. I guess there are other PHY drivers which too support HW controlled blinking modes. So of this way of controlling PHY LED HW controlled modes is accepted, the code creating the hw-control trigger and hw_control file should be made into library code so that it can be reused. What do you think? Marek Marek Behún (1): net: phy: marvell: add support for PHY LEDs via LED class drivers/net/phy/Kconfig | 7 + drivers/net/phy/marvell.c | 423 +- 2 files changed, 429 insertions(+), 1 deletion(-) -- 2.26.2
[PATCH RFC leds + net-next v2 1/1] net: phy: marvell: add support for PHY LEDs via LED class
This patch adds support for controlling the LEDs connected to several
families of Marvell PHYs via Linux' LED API. These families are:
88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can be
added.
The code reads LEDs definitions from the device-tree node of the PHY.
Since the LEDs can be controlled by hardware, we add one LED-private LED
trigger named "hw-control". This trigger is private and displayed only
for Marvell PHY LEDs.
When this driver is activated, another sysfs file is created in that
LEDs sysfs directory, names "hw_control". This file contains space
separated list of possible HW controlled modes for this LED. The one
which is selected is enclosed by square brackets. To change HW control
mode the user has to write the name of desired mode to this "hw_control"
file.
This patch does not yet add support for compound LED modes. This could
be achieved via the LED multicolor framework (which is not yet in
upstream).
Settings such as HW blink rate or pulse stretch duration are not yet
supported, nor are LED polarity settings.
Signed-off-by: Marek Behún
---
drivers/net/phy/Kconfig | 7 +
drivers/net/phy/marvell.c | 423 +-
2 files changed, 429 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index dd20c2c27c2f..fb75abdb9f24 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -456,6 +456,13 @@ config MARVELL_PHY
help
Currently has a driver for the 88E1011S
+config MARVELL_PHY_LEDS
+ bool "Support LEDs on Marvell PHYs"
+ depends on MARVELL_PHY && LEDS_TRIGGERS
+ help
+ This option enables support for controlling LEDs connected to Marvell
+ PHYs.
+
config MARVELL_10G_PHY
tristate "Marvell Alaska 10Gbit PHYs"
help
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bb86ac0bd092..e2bb2cc889ef 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -148,6 +149,11 @@
#define MII_88E1510_PHY_LED_DEF0x1177
#define MII_88E1510_PHY_LED0_LINK_LED1_ACTIVE 0x1040
+#define MII_PHY_LED45_CTRL 19
+
+#define MII_PHY_LED_CTRL_FORCE_ON 0x9
+#define MII_PHY_LED_CTRL_FORCE_OFF 0x8
+
#define MII_M1011_PHY_STATUS 0x11
#define MII_M1011_PHY_STATUS_1000 0x8000
#define MII_M1011_PHY_STATUS_100 0x4000
@@ -252,6 +258,8 @@
#define LPA_PAUSE_FIBER0x180
#define LPA_PAUSE_ASYM_FIBER 0x100
+#define MARVELL_PHY_MAX_LEDS 6
+
#define NB_FIBER_STATS 1
MODULE_DESCRIPTION("Marvell PHY driver");
@@ -271,10 +279,23 @@ static struct marvell_hw_stat marvell_hw_stats[] = {
{ "phy_receive_errors_fiber", 1, 21, 16},
};
+struct marvell_phy_led {
+ struct led_classdev cdev;
+ u8 idx;
+ /* register value when in HW ctrl mode */
+ u8 regval;
+};
+
+#define to_marvell_phy_led(l) container_of(l, struct marvell_phy_led, cdev)
+
struct marvell_priv {
u64 stats[ARRAY_SIZE(marvell_hw_stats)];
char *hwmon_name;
struct device *hwmon_dev;
+#if IS_ENABLED(CONFIG_MARVELL_PHY_LEDS)
+ struct marvell_phy_led leds[MARVELL_PHY_MAX_LEDS];
+ u32 led_flags;
+#endif
bool cable_test_tdr;
u32 first;
u32 last;
@@ -662,6 +683,379 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
return err;
}
+#if IS_ENABLED(CONFIG_MARVELL_PHY_LEDS)
+
+static struct led_hw_trigger_type marvell_led_trigger_type;
+
+enum {
+ L1V0_RECV = BIT(0),
+ L1V0_COPPER = BIT(1),
+ L1V5_100_FIBER = BIT(2),
+ L1V5_100_10 = BIT(3),
+ L2V2_INIT = BIT(4),
+ L2V2_PTP= BIT(5),
+ L2V2_DUPLEX = BIT(6),
+ L3V0_FIBER = BIT(7),
+ L3V0_LOS= BIT(8),
+ L3V5_TRANS = BIT(9),
+ L3V7_FIBER = BIT(10),
+ L3V7_DUPLEX = BIT(11),
+};
+
+struct marvell_led_ctrl_info {
+ const char *name;
+ s8 regval[MARVELL_PHY_MAX_LEDS];
+ u32 flags;
+};
+
+static const struct marvell_led_ctrl_info marvell_led_ctrl_info[] = {
+ { "link/nolink",{ 0x0, -1, 0x0, -1, -1, -1, }, 0 },
+ { "link/act/nolink",{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 },
+ { "1000/100/10/nolink", { 0x2, -1, -1, -1, -1, -1, }, 0 },
+ { "act/noact", { 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, }, 0 },
+ { "blink-act/noact",{ 0x4, 0x4, 0x4, 0x4, 0x4, 0x4, }, 0 },
+ { "transmit/notransmit",{ 0x5, -1, 0x5, -1, 0x5, 0x5, }, 0 },
+ { "transmi
Re: [PATCH RFC leds + net-next v2 0/1] Add support for LEDs on Marvell PHYs
On Fri, 24 Jul 2020 12:29:01 +0200
Pavel Machek wrote:
> In future, would you expect having software "1000/100/10/nolink"
> triggers I could activate on my scrollock LED (or on GPIO controlled
> LEDs) to indicate network activity?
Look at drivers/net/phy/phy_led_triggers.c, something like that could
be actually implemented there.
Some of the modes are useful, like the "1000/100/10/nolink". But some
of them are pretty weird, and I don't think anyone actually uses it
("1000-10/else", which is on if the device is linked at 1000mbps ar
10mbps, and else off? who would sacrifies a LED for this?).
I actually wanted to talk about the phy_led_triggers.c code. It
registers several trigger for each PHY, with the name in form:
phy-device-name:mode
where
phy-device-name is derived from OF
- sometimes it is in the form
d0032004.mdio-mii:01
- but sometimes in the form of whole OF path followed by ":" and
the PHY address:
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:08
mode is "link", "1Gbps", "100Mbps", "10Mbps" and so on"
So I have a GPIO LED, and I can set it to sw trigger so that it is on
when a specific PHY is linked on 1Gbps.
The problem is that on Turris Mox I can connect up to three 8-port
switches, which yields in 25 network PHYs overall. So reading the
trigger file results in 4290 bytes (look at attachment cat_trigger.txt).
I think the phy_led_triggers should have gone this way of having just
one trigger (like netdev has), and specifying phy device via and mode
via another file.
Marek
none timer oneshot heartbeat default-on [mmc0] mmc1
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:01:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:01:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:01:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:01:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:02:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:02:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:02:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:02:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:03:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:03:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:03:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:03:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:04:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:04:1Gbps
/soc/internal-regs@d000/mdio@32004/switch
1@11/mdio:04:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:04:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:05:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:05:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:05:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:05:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:06:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:06:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:06:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:06:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:07:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:07:1Gbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:07:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:07:10Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:08:link
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:08:1Gbps /soc/inter
nal-regs@d000/mdio@32004/switch1@11/mdio:08:100Mbps
/soc/internal-regs@d000/mdio@32004/switch1@11/mdio:08:10Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:01:link
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:01:1Gbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:01:100Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:01:10Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:02:link
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:02:1Gbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:02:100Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:02:10Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:03:link
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:03:1Gbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:03:100Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:03:10Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:04:link
/soc/internal-regs@d000/mdio@32004/
switch0@10/mdio:04:1Gbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:04:100Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:04:10Mbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:05:link
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:05:1Gbps
/soc/internal-regs@d000/mdio@32004/switch0@10/mdio:05:100Mbps
/soc/internal-regs@d000/mdio@32004/switch0
Re: [PATCH RFC leds + net-next v2 0/1] Add support for LEDs on Marvell PHYs
On Fri, 24 Jul 2020 15:12:33 +0200
Marek Behún wrote:
> On Fri, 24 Jul 2020 12:29:01 +0200
> Pavel Machek wrote:
>
> > In future, would you expect having software "1000/100/10/nolink"
> > triggers I could activate on my scrollock LED (or on GPIO controlled
> > LEDs) to indicate network activity?
>
> Look at drivers/net/phy/phy_led_triggers.c, something like that could
> be actually implemented there.
>
> Some of the modes are useful, like the "1000/100/10/nolink". But some
> of them are pretty weird, and I don't think anyone actually uses it
> ("1000-10/else", which is on if the device is linked at 1000mbps ar
> 10mbps, and else off? who would sacrifies a LED for this?).
>
> I actually wanted to talk about the phy_led_triggers.c code. It
> registers several trigger for each PHY, with the name in form:
> phy-device-name:mode
> where
> phy-device-name is derived from OF
> - sometimes it is in the form
> d0032004.mdio-mii:01
> - but sometimes in the form of whole OF path followed by ":" and
> the PHY address:
> /soc/internal-regs@d000/mdio@32004/switch0@10/mdio:08
> mode is "link", "1Gbps", "100Mbps", "10Mbps" and so on"
>
> So I have a GPIO LED, and I can set it to sw trigger so that it is on
> when a specific PHY is linked on 1Gbps.
>
> The problem is that on Turris Mox I can connect up to three 8-port
> switches, which yields in 25 network PHYs overall. So reading the
> trigger file results in 4290 bytes (look at attachment
> cat_trigger.txt). I think the phy_led_triggers should have gone this
> way of having just one trigger (like netdev has), and specifying phy
> device via and mode via another file.
>
> Marek
>
In fact I think the way the phy_led_triggers does this should be
deprecated. I new kernel config options should be create, something
like "new user API for PHY LED trigger", which would create just one
trigger, with name phydev, like we have netdev, and like in the netdev
trigger, the mode and device should be configured via other files.
This phydev trigger could then be made similar to phy-hw-mode trigger...
Marek
[PATCH RFC leds + net-next v3 0/2] Add support for LEDs on Marvell PHYs
Hi, this is v3 of my RFC adding support for LEDs connected to Marvell PHYs. Please note that if you want to test this, you still need to first apply the patch adding the LED private triggers support from Pavel's tree. https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next&id=93690cdf3060c61dfce813121d0bfc055e7fa30d Changes since v2: - to share code with other drivers which may want to also offer PHY HW control of LEDs some of the code was refactored and now resides in phy_hw_led_mode.c. This code is compiled in when config option LED_TRIGGER_PHY_HW is enabled. Drivers wanting to offer PHY HW control of LEDs should depend on this option. - the "hw-control" trigger is renamed to "phydev-hw-mode" and is registered by the code in phy_hw_led_mode.c - the "hw_control" sysfs file is renamed to "hw_mode" - struct phy_driver is extended by three methods to support PHY HW LED control - I renamed the various HW control modes offeret by Marvell PHYs to conform to other Linux mode names, for example the "1000/100/10/else" mode was renamed to "1Gbps/100Mbps/10Mbps", or "recv/else" was renamed to "rx" (this is the name of the mode in netdev trigger). Marek Marek Behún (2): net: phy: add API for LEDs controlled by PHY HW net: phy: marvell: add support for PHY LEDs via LED class drivers/net/phy/Kconfig | 10 + drivers/net/phy/Makefile | 1 + drivers/net/phy/marvell.c | 364 ++ drivers/net/phy/phy_hw_led_mode.c | 96 include/linux/phy.h | 15 ++ 5 files changed, 486 insertions(+) create mode 100644 drivers/net/phy/phy_hw_led_mode.c -- 2.26.2
[PATCH RFC leds + net-next v3 2/2] net: phy: marvell: add support for PHY LEDs via LED class
This patch adds support for controlling the LEDs connected to several
families of Marvell PHYs via the PHY HW LED trigger API. These families
are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can
be added.
The code reads LEDs definitions from the device-tree node of the PHY.
This patch does not yet add support for compound LED modes. This could
be achieved via the LED multicolor framework (which is not yet in
upstream).
Settings such as HW blink rate or pulse stretch duration are not yet
supported, nor are LED polarity settings.
Signed-off-by: Marek Behún
---
drivers/net/phy/Kconfig | 1 +
drivers/net/phy/marvell.c | 364 ++
2 files changed, 365 insertions(+)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index ffea11f73acd..5428a8af26d2 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -462,6 +462,7 @@ config LXT_PHY
config MARVELL_PHY
tristate "Marvell PHYs"
+ depends on LED_TRIGGER_PHY_HW
help
Currently has a driver for the 88E1011S
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index bb86ac0bd092..08cd79a1aa8d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -148,6 +149,11 @@
#define MII_88E1510_PHY_LED_DEF0x1177
#define MII_88E1510_PHY_LED0_LINK_LED1_ACTIVE 0x1040
+#define MII_PHY_LED45_CTRL 19
+
+#define MII_PHY_LED_CTRL_FORCE_ON 0x9
+#define MII_PHY_LED_CTRL_FORCE_OFF 0x8
+
#define MII_M1011_PHY_STATUS 0x11
#define MII_M1011_PHY_STATUS_1000 0x8000
#define MII_M1011_PHY_STATUS_100 0x4000
@@ -252,6 +258,8 @@
#define LPA_PAUSE_FIBER0x180
#define LPA_PAUSE_ASYM_FIBER 0x100
+#define MARVELL_PHY_MAX_LEDS 6
+
#define NB_FIBER_STATS 1
MODULE_DESCRIPTION("Marvell PHY driver");
@@ -271,10 +279,19 @@ static struct marvell_hw_stat marvell_hw_stats[] = {
{ "phy_receive_errors_fiber", 1, 21, 16},
};
+struct marvell_phy_led {
+ struct led_classdev cdev;
+ u8 idx;
+};
+
+#define to_marvell_phy_led(l) container_of(l, struct marvell_phy_led, cdev)
+
struct marvell_priv {
u64 stats[ARRAY_SIZE(marvell_hw_stats)];
char *hwmon_name;
struct device *hwmon_dev;
+ struct marvell_phy_led leds[MARVELL_PHY_MAX_LEDS];
+ u32 led_flags;
bool cable_test_tdr;
u32 first;
u32 last;
@@ -662,6 +679,333 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
return err;
}
+enum {
+ L1V0_RECV = BIT(0),
+ L1V0_COPPER = BIT(1),
+ L1V5_100_FIBER = BIT(2),
+ L1V5_100_10 = BIT(3),
+ L2V2_INIT = BIT(4),
+ L2V2_PTP= BIT(5),
+ L2V2_DUPLEX = BIT(6),
+ L3V0_FIBER = BIT(7),
+ L3V0_LOS= BIT(8),
+ L3V5_TRANS = BIT(9),
+ L3V7_FIBER = BIT(10),
+ L3V7_DUPLEX = BIT(11),
+};
+
+struct marvell_led_mode_info {
+ const char *name;
+ s8 regval[MARVELL_PHY_MAX_LEDS];
+ u32 flags;
+};
+
+static const struct marvell_led_mode_info marvell_led_mode_info[] = {
+ { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
+ { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 },
+ { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1, -1, -1, -1, }, 0 },
+ { "act",{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, }, 0 },
+ { "blink-act", { 0x4, 0x4, 0x4, 0x4, 0x4, 0x4, }, 0 },
+ { "tx", { 0x5, -1, 0x5, -1, 0x5, 0x5, }, 0 },
+ { "tx", { -1, -1, -1, 0x5, -1, -1, },
L3V5_TRANS },
+ { "rx", { -1, -1, -1, -1, 0x0, 0x0, }, 0 },
+ { "rx", { -1, 0x0, -1, -1, -1, -1, },
L1V0_RECV },
+ { "copper", { 0x6, -1, -1, -1, -1, -1, }, 0 },
+ { "copper", { -1, 0x0, -1, -1, -1, -1, },
L1V0_COPPER },
+ { "1Gbps", { 0x7, -1, -1, -1, -1, -1, }, 0 },
+ { "link/rx",{ -1, 0x2, -1, 0x2, 0x2, 0x2, }, 0 },
+ { "100Mbps-fiber", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_FIBER },
+ { "100Mbps-10Mbps", { -1, 0x5, -1, -1, -1, -1, },
L1V5_100_10 },
+ { "1Gbps-100Mbps", { -1, 0x6, -1, -1, -1, -1, }, 0 },
+ { "1Gbps-10Mbps", { -1, -1, 0x6, 0x6, -1, -1, }, 0 },
+ {
