Linux now has incomplete support for the LED controller on Turris Omnia:
it can set brightness and colors for each LED.
The controller can also put these LEDs into HW controlled mode, in which
the LEDs are controlled by HW: for example the WAN LED is connected via
MCU to the WAN PHY LED pin.
The driver does not support these HW controlled modes yet, and on probe
puts the LEDs into SW controlled mode.
Add node describing the LED controller, but disable it for now.
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Andreas Färber <afaerber@suse.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
LED core does not allow LED_COLOR_ID_MULTI for now and instead for RGB
LEDs prefers LED_COLOR_ID_RGB.
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 77dce3a22e ("leds: disallow /sys/class/leds/*:multi:* for now")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Although checkpatch changed the max-line-length default to 100 columns,
we still prefer 80 columns somewhere.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use integer constants directly when building I2C messages for LED color
change command, instead of macros. The command is simple enough to
understand what is going on even without these names.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The contents of the Future Development section of leds-class
Documentation was invalidated when support for LED-private triggers
was merged. Remove this section.
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 93690cdf30 ("leds: trigger: add support for LED-private device...")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Do not match OF match pointer with of_match_ptr, so that even if
CONFIG_OF is disabled, the driver can still be bound via another method.
Move definition of of_ns2_leds_match just before ns2_led_driver
definition, since it is not needed sooner.
Signed-off-by: Marek Behún <kabel@kernel.org>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert from OF api to fwnode API, so that it is possible to bind this
driver without device-tree.
The fwnode API does not expose a function to read a specific element of
an array. We therefore change the types of the ns2_led_modval structure
so that we can read the whole modval array with one fwnode call.
Signed-off-by: Marek Behún <kabel@kernel.org>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"pca963x:%d:%.2x:%u"
For backwards compatibility we therefore set init_data->default_label
to this value so that the LED will not get a different name if `label`
property is not present, nor are `color` and `function`.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Peter Meerwald <p.meerwald@bct-electronic.com>
Cc: Ricardo Ribalda <ribalda@kernel.org>
Cc: Zahari Petkov <zahari@balena.io>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Register LEDs immediately after parsing their properties.
This allows us to get rid of platdata, and since no one in tree uses
header linux/platform_data/leds-pca963x.h, remove it.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Peter Meerwald <p.meerwald@bct-electronic.com>
Cc: Ricardo Ribalda <ribalda@kernel.org>
Cc: Zahari Petkov <zahari@balena.io>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Remove the binding comment at the beginning. The information for
platdata is now obsolete and DT binding is documented in device-tree
bindings.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: NeilBrown <neilb@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variables: instead of writing &client->dev at many places,
write only dev. The same with pca963x->chip->chipdef,
pca963x->chip->client).
Use helper variable u8 val for i2c_smbus_write_byte_data, for better
indentation.
Indent better on various places.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Peter Meerwald <p.meerwald@bct-electronic.com>
Cc: Ricardo Ribalda <ribalda@kernel.org>
Cc: Zahari Petkov <zahari@balena.io>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix potential ERR_PTR(0).
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: d78b10f5713d9 ("leds: tca6507: use fwnode API instead of OF")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert to use fwnode API instead of OF. It is more generic and if
someone wants to use this driver without device-tree yet still, they
will be able to via swnode fwnodes.
Remove the gpio setup function from platdata.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: NeilBrown <neilb@suse.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The only in-tree usage of this driver is via device-tree. No on else
includes linux/leds-tca6507.h, so absorb the definition of platdata
structure.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: NeilBrown <neilb@suse.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Build this driver on another platforms if COMPILE_TEST=y. Another
drivers may depend on this, for example leds-asic3.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Do the parsing of `linux,default-trigger` DT property to LED core.
Currently it is done in many different drivers and the code is repeated.
This patch removes the parsing from 23 drivers:
an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio,
is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593,
max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia.
There is one driver in drivers/input which parses this property on it's
own. I shall send a separate patch there after this is applied.
There are still 8 drivers that parse this property on their own because
they do not pass the led_init_data structure to the registering
function. I will try to refactor those in the future.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver uses extended LED registration, so we do not need to parse
the `label` DT property on our own.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Now that the potential use-after-free issue is resolved we can use
devres for LED registration in this driver.
By using devres version of LED registering function we can remove the
.remove method from this driver.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Instead of registering LED under the MFD device, this driver sets the
parent of the LED it is registering to the parent of the MFD device (the
I2C client device).
Because of this we cannot use devres for LED registration, since it can
result in use-after-free, see commit
a0972fff09 ("leds: lm36274: fix use-after-free on unbind").
The only other in-tree driver that also registers under the MFD device
(drivers/regulator/lm363x-regulator.c) sets the parent to the MFD
device.
Set the parent of this LED to the MFD device, instead of the I2C client
device.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These settings are not parsed from DT and therefore semantically should
not be set in function with a name lm36274_parse_dt.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"parent_name::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present, nor are `color` and `function`.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Do not use device_for_each_child_node. Since this driver works only with
once child node present, use device_get_next_child_node instead.
This also saves one level of indentation.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Rename this variable so that it is easier to read and easier to write in
80 columns. Also rename variable of this type in lm36274_brightness_set
from led to chip, to be consistent.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Move forward from platform data to device tree only.
Since commit c7896490dd ("leds: ns2: Absorb platform data") the
platform data structure is absorbed into the driver, because nothing
else in the source tree uses it. Since nobody complained and all usage
of this driver is via device tree, change the code to work with device
tree only. As Linus Walleij wrote, the device tree should be the
preferred way forward anyway.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Simon Guinot <sguinot@lacie.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: David Rivshin <drivshin@allworx.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Since init_data is passed with fwnode handle, we do not need to set
the of_node member of the newly created LED classdev.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: John Crispin <john@phrozen.org>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"max77650::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use helper variable dev instead of always writing &client->dev, or
&priv->client->dev, or even &led->priv->client->dev.
With one more line moved reverse christmas tree is also achieved.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Previously if the `label` DT property was not present, the code composed
name for the LED in the form
"parent_name::"
For backwards compatibility we therefore set
init_data->default_label = ":";
so that the LED will not get a different name if `label` property is not
present.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
By using struct led_init_data when registering we do not need to parse
`label` DT property. Moreover `label` is deprecated and if it is not
present but `color` and `function` are, LED core will compose a name
from these properties instead.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Álvaro Fernández Rojas <noltari@gmail.com>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These two drivers do not provide remove method and use devres for
allocation of other resources, yet they use led_classdev_register
instead of the devres variant, devm_led_classdev_register.
Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Álvaro Fernández Rojas <noltari@gmail.com>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Jaedon Shin <jaedon.shin@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Cc: stable@kernel.org
Fix OF node leaks by calling of_node_put in
for_each_available_child_of_node when the cycle breaks or returns.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Nikita Travkin <nikitos.tr@gmail.com>
Cc: Milo Kim <milo.kim@ti.com>
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Not-for-stable: untested, theoretical, insignificant leaks
The devm_led_classdev_register_ext is given init_data with fwnode set,
so the LED core sets .of_node of the new LED classdev correctly.
Do not rewrite this value to parent of_node.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
These drivers can be compiled without modification when COMPILE_TEST=y:
cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Commit c3e302edca ("net: phy: marvell10g: fix temperature sensor on 2110")
added a check for PHY ID via phydev->drv->phy_id in a function which is
called by devres at a time when phydev->drv is already set to null by
phy_remove function.
This null pointer dereference can be triggered via SFP subsystem with a
SFP module containing this Marvell PHY. When the SFP interface is put
down, the SFP subsystem removes the PHY.
Fixes: c3e302edca ("net: phy: marvell10g: fix temperature sensor on 2110")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Document the global brightness attribute for the Turris Omnia LED
controller.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This adds basic support for LEDs on the front side of CZ.NIC's Turris
Omnia router.
There are 12 RGB LEDs. The controller supports HW triggering mode for
the LEDs, but this driver does not support it yet, and sets all the LEDs
defined in device-tree into SW mode upon probe.
This driver uses the multicolor LED framework.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Some LED controllers may come with an internal HW triggering mechanism
for the LED and the ability to switch between SW control and the
internal HW control. This includes most PHYs, various ethernet switches,
the Turris Omnia LED controller or AXP20X PMIC.
This adds support for registering such triggers.
This code is based on work by Pavel Machek <pavel@ucw.cz> and
Ondřej Jirman <megous@megous.com>.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The firmware on Turris MOX secure processor offers signing messages
with ECDSA private key stored in protected OTP memory.
The optimal solution would be to register an akcipher provider via
kernel's crypto API, but crypto API does not yet support accessing
akcipher API from userspace (and probably won't for some time, see
https://www.spinics.net/lists/linux-crypto/msg38388.html).
At first I tried to put this via standard sysfs API, but the way I
designed it is not compatible with sysfs's standard "one file per
attribute".
This patch therefore adds support for accessing this signature
generation mechanism via debugfs. Since CZ.NIC's Turris MOX is the only
user of this module, the potential future change to akcipher API should
not cause problems, since we can just change our userspace software then.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
With recent proposed changes for U-Boot it is possible that bootloader
won't initialize the PHY for this controller (currently the PHY is
initialized regardless whether PCI is used in U-Boot, but with these
proposed changes the PHY is initialized only on request).
Since the mvebu-a3700-comphy driver by Miquèl Raynal supports enabling
PCIe PHY, and since Linux' functionality should be independent on what
bootloader did, add code for enabling generic PHY if found in device OF
node.
The mvebu-a3700-comphy driver does PHY powering via SMC calls to ARM
Trusted Firmware. The corresponding code in ARM Trusted Firmware skips
one register write which U-Boot does not: step 7 ("Enable TX"), see [1].
Instead ARM Trusted Firmware expects PCIe driver to do this step,
probably because the register is in PCIe controller address space,
instead of PHY address space. We therefore add this step into the
advk_pcie_setup_hw function.
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/drivers/marvell/comphy/phy-comphy-3700.c?h=v2.3-rc2#n836
Link: https://lore.kernel.org/r/20200430080625.26070-8-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Miquèl Raynal <miquel.raynal@bootlin.com>
Currently the aardvark driver trains link in PCIe gen2 mode. This may
cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or
even not detected. Moreover when ASPM code tries to retrain link second
time, these cards may stop responding and link goes down. If gen1 is
used this does not happen.
Unconditionally forcing gen1 is not a good solution since it may have
performance impact on gen2 cards.
To overcome this, read 'max-link-speed' property (as defined in PCI
device tree bindings) and use this as max gen mode. Then iteratively try
link training at this mode or lower until successful. After successful
link training choose final controller gen based on Negotiated Link Speed
from Link Status register, which should match card speed.
Link: https://lore.kernel.org/r/20200430080625.26070-5-pali@kernel.org
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The sfp compatible should be 'sff,sfp', not 'sff,sfp+'. We used patched
kernel where the latter was working.
Fixes: 7109d817db ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Use sdhci-caps-mask to forbid SDR104 mode on the SDIO capable SDHCI
controller. Without this the device cannot pass electromagnetic
interference certifications.
Fixes: 7109d817db ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Move the comphy handle property of the PCIe node from board specific
device tree files (EspressoBin and Turris Mox) to the generic
armada-37xx.dtsi.
This is correct since this is the only possible PCIe PHY configuration
on Armada 37xx, so when PCIe is enabled on any board, this handle is
correct.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
We found out that we are unable to control the PERST# signal via the
default pin dedicated to be PERST# pin (GPIO2[3] pin) on A3700 SOC when
this pin is in EP_PCIE1_Resetn mode. There is a register in the PCIe
register space called PERSTN_GPIO_EN (D0088004[3]), but changing the
value of this register does not change the pin output when measuring
with voltmeter.
We do not know if this is a bug in the SOC, or if it works only when
PCIe controller is in a certain state.
Commit f4c7d053d7 ("PCI: aardvark: Wait for endpoint to be ready
before training link") says that when this pin changes pinctrl mode
from EP_PCIE1_Resetn to GPIO, the PERST# signal is asserted for a brief
moment.
So currently the situation is that on A3700 boards the PERST# signal is
asserted in U-Boot (because the code in U-Boot issues reset via this pin
via GPIO mode), and then in Linux by the obscure and undocumented
mechanism described by the above mentioned commit.
We want to issue PERST# signal in a known way, therefore this patch
changes the pcie_reset_pin function from "pcie" to "gpio" and adds the
reset-gpios property to the PCIe node in device tree files of
EspressoBin and Armada 3720 Dev Board (Turris Mox device tree already
has this property and uDPU does not have a PCIe port).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Remi Pommarel <repk@triplefau.lt>
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 8d876bf472 ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When CONFIG_RESET_CONTROLLER is disabled, the
devm_reset_control_get_exclusive function returns -ENOTSUPP. This is not
handled in subsequent check and then the mdio device fails to probe.
When CONFIG_RESET_CONTROLLER is enabled, its code checks in OF for reset
device, and since it is not present, returns -ENOENT. -ENOENT is handled.
Add -ENOTSUPP also.
This happened to me when upgrading kernel on Turris Omnia. You either
have to enable CONFIG_RESET_CONTROLLER or use this patch.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 71dd6c0dff ("net: phy: add support for reset-controller")
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add the node representing the firmware running on the secure processor.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Update Turris Mox device tree to use the phy-supply property of the
generic PHY framework instead of the legacy usb-phy property.
This is needed since it caused a regression on Turris Mox since "usb:
host: xhci-plat: Prevent an abnormally restrictive PHY init skipping".
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: eb6c2eb6c7 ("usb: host: xhci-plat: Prevent an abnormally restrictive PHY init skipping")
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
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 read
some information burned into eFuses when device was manufactured:
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
The firmware is also able to, on demand, sign messages with the burned
ECDSA private key, but since Linux's akcipher API is not yet stable
(and therefore not exposed to userspace via netlink), this functionality
is not supported yet.
Link: https://lore.kernel.org/r/20190822014318.19478-3-marek.behun@nic.cz
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 board can be extended by different modules.
If those are connected, U-Boot lets the kernel know via device-tree.
Since modules can be connected in different order and some modules can
be connected multiple times (up to three modules containing 8-port
ethernet switch in DSA configuration can be connected) we decided
against using device-tree overlays, because it got complicated rather
quickly. (For example the SFP module can be connected directly to the
CPU, or after a switch module. There are four cases and all would need
different SFP overlay. There are two types of switch modules (8-port
with pass-through and 4-port with no pass-through). For those we would
again need at least 6 more overlays.)
We therefore decided to put all the possibly connected devices in one
device-tree and disable them by default. When U-Boot finds out which
modules are connected, it fixes the loaded device-tree accordingly just
before boot. By Rob Herring's suggestion we also made it so that U-Boot
completely removes nodes which are disabled after this fixup.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Rob Herring <robh@kernel.org>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Currently we support SERDES on the Topaz family in a limited way: no
IRQs and the cmode is not writable, thus the mode is determined by
strapping pins.
Marvell's examples though show how to make cmode writable on port 5 and
support SGMII autonegotiation. It is done by writing hidden registers,
for which we already have code.
This patch adds support for making the cmode for the SERDES port
writable on the Topaz family, via a new chip operation,
.port_set_cmode_writable, which is called from mv88e6xxx_port_setup_mac
just before .port_set_cmode.
SERDES IRQs are also enabled for Topaz.
Tested on Turris Mox.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a cosmetic update. We are removing the last underscore from
macros MV88E6XXX_PORT_STS_CMODE_100BASE_X and
MV88E6XXX_PORT_STS_CMODE_1000BASE_X. The 2500base-x version does not
have that underscore. Also PHY_INTERFACE_MODE_ macros do not have it
there.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Marek Behún