e
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
---
Doc
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
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
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: li
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 modul
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
.
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
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
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
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|
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
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
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
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
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 +
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
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
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
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
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
.
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
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
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
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
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
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
S 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
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
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
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
.
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
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
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 o
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
/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
t;)
>
> Signed-off-by: Rui Salvaterra
Reviewed-by: Marek Behún
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
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 de
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 w
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 modul
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
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 verifi
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 a
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 struc
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
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
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 shoul
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 explici
> + /* 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)
> +
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 be
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
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
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
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
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. P
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 mul
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
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 ++
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
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
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
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 sy
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 contro
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 hav
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 trig
Reviewed-by: Marek Behún
"couldn't register LED %s\n",
> led->ldev.name);
> + }
> }
> return 0;
> }
Reviewed-by: Marek Behún
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
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
s 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: ph
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
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
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 2500Base
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) {
>
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 w
changed, 10 insertions(+), 12 deletions(-)
>
Reviewed-by: Marek Behún
--
> 1 file changed, 10 insertions(+), 9 deletions(-)
Reviewed-by: Marek Behún
e/bindings/leds/leds-class-multicolor.yaml
Reviewed-by: Marek Behún
or.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
s/leds/led-core.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Marek Behún
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
#x27;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
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
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
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
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 & Pal
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
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
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
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
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
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
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);
> +
> +
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
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
des. 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
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 c
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 controlle
t;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 |
.
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
1 - 100 of 189 matches
Mail list logo
