Hi Ole Kristian,
On Tue, 2022-06-07 at 08:56 +0200, Ole Kristian Lona wrote:
> Hello, Sander!
>
> I haven't had time to check the rest of the stuff I was working on for Deco
> M4R v3 and M5, but
> when I see this patch, and think of the work we did in the last round, I
> can't help thinking
Hi,
has anyone tested that??? This does not make sense at all, there is no LED
disable
in the LED_GLB_CTRL register. Instead one needs to use
RTL9310_MAC_L2_GLOBAL_CTRL2
The following works nicely on the XS1930 and Edgecore:
pinmux: pinmux@1b001358 {
compatible =
Like for RTL838x devices, add a pinctrl-single node to manage the
sys-led/gpio0 mux, and allow using the pin as GPIO.
Co-developed-by: INAGAKI Hiroshi
Signed-off-by: INAGAKI Hiroshi
Signed-off-by: Sander Vanheule
---
target/linux/realtek/dts-5.10/rtl930x.dtsi | 15 +++
1 file
CPU clock definition in devicetree should be specified per CPU, not in
the cpus node.
The implementation of plat_init_time() needs to be modified to look for
the clock frequency in the changed location. To achieve this, the
relevant code is copied from the generic MIPS implementation in
Hi Birger,
On Tue, 2022-06-07 at 11:26 +0200, Birger Koblitz wrote:
> Hi,
>
> On 07.06.22 11:04, Sander Vanheule wrote:
> > On Tue, 2022-06-07 at 10:15 +0200, Birger Koblitz wrote:
> > > Hi,
> > >
> > > has anyone tested that???
> >
> > I don't have any 931x hardware, but it is based on what
The devicetree for the ZyXEL XGS1250-12 was missing the description of
the front panel LED labeled "PWR SYS". Let's add it so it can be
controlled by the user.
Signed-off-by: Sander Vanheule
---
.../dts-5.10/rtl9302_zyxel_xgs1250-12.dts | 21 +++
1 file changed, 21
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello, Sander!
I haven't had
Add a pinctrl-single node to manage the sys-led mux and JTAG mux.
This allows using the associated pins as GPIOs:
- sys-led: GPIO0
- JTAG: GPIO6, GPIO7, others unknown (TDO, TDI, TMS, TCK /TRST)
Suggested-by: Birger Koblitz
Signed-off-by: Sander Vanheule
---
Defining how the system LED is set up, and configuring the sys-led pin
mux should be done using devictree info. Currently the toggle rate is
set up unconditionally in the setup.c platform file. This may simply be
pointless, if the pin is used as GPIO, or may wreak havoc on devices
using the
Defining how the system LED is set up, and configuring the sys-led pin
mux should be done using devictree info. Currently this is set up
unconditionally in the setup.c platform file, which may wreak havoc on
devices using the sys-led peripheral as somehting else than a user GPIO.
This series add
Like for RTL838x devices, add a pinctrl-single node to manage the
sys-led/gpio0 mux, and allow using the pin as GPIO.
Co-developed-by: INAGAKI Hiroshi
Signed-off-by: INAGAKI Hiroshi
Signed-off-by: Sander Vanheule
---
target/linux/realtek/dts-5.10/rtl930x.dtsi | 15 +++
1 file
setup.c unconditionally sets the sys-led mode (blinking rate) to a
permanent high output. This may cause issues when a board expects this
pin to toggle periodically, e.g. when hooked up to an external watchdog.
If the sys-led peripheral is used to control an LED, the mux should be
configured to
Disabling the sys-led peripheral should be done via a pin controller,
for which pinctrl-single nodes are present in the platform DTSI files.
Drop the hardcoded per-platform sys-led configurations, and require
things to be set up in the devicetree.
Co-developed-by: INAGAKI Hiroshi
Signed-off-by:
The devicetree for the ZyXEL XGS1250-12 was missing the description of
the front panel LED labeled "PWR SYS". Let's add it so it can be
controlled by the user.
Signed-off-by: Sander Vanheule
---
.../dts-5.10/rtl9302_zyxel_xgs1250-12.dts | 21 +++
1 file changed, 21
On Tue, 2022-06-07 at 10:24 +0200, Birger Koblitz wrote:
> Hi,
>
> at least for the RTL931x, removing the rtl931x_setup() is not a good idea as
> the WDT reset does
> not work for that architecture.
> The only way to get a working reset is via registering a reset handler:
>
> static void __init
Hi,
On 07.06.22 11:10, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:24 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> at least for the RTL931x, removing the rtl931x_setup() is not a good idea as
>> the WDT reset does
>> not work for that architecture.
>> The only way to get a working reset is
Hi,
On 07.06.22 11:04, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:15 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> has anyone tested that???
>
> I don't have any 931x hardware, but it is based on what you put into setup.c.
What is in the setup.c makes the System LED solid on. It is the same
Well. I'm using the ap right now without doing further operations
other than switching the driver. How can I check if I need to do the
thing about the caldata partition you're asking me?
UPDATE: while I was writing this email the AP started dropping packets
on the 5GHz network. Rebooting the AP
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Agreed!
I will write and test
On Tue, 2022-06-07 at 10:15 +0200, Birger Koblitz wrote:
> Hi,
>
> has anyone tested that???
I don't have any 931x hardware, but it is based on what you put into setup.c.
> This does not make sense at all, there is no LED disable
> in the LED_GLB_CTRL register. Instead one needs to use
>
UPDATE: it started dropping packets on 2,4GHz too. Now I tried to
power it off and wait. Maybe my PoE injector has problems, or the AP
itself.
Il giorno mar 7 giu 2022 alle ore 09:21 Alessandro Fellin
ha scritto:
>
> Well. I'm using the ap right now without doing further operations
> other than
Not all devices using the gpio0/sys-led pin as a GPIO, configure the
pinmux. Add the necessary pinctrl properties to these devices to ensure
the pin is set up for use as GPIO.
Co-developed-by: INAGAKI Hiroshi
Signed-off-by: INAGAKI Hiroshi
Signed-off-by: Sander Vanheule
Tested-by: Bjørn Mork
Like for RTL838x devices, add a pinctrl-single node to manage the
sys-led/gpio0 mux, and allow using the pin as GPIO.
Signed-off-by: Sander Vanheule
---
target/linux/realtek/dts-5.10/rtl931x.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git
Hi,
at least for the RTL931x, removing the rtl931x_setup() is not a good idea as
the WDT reset does not work for that architecture.
The only way to get a working reset is via registering a reset handler:
static void __init rtl931x_setup(void)
{
pr_info("Registering _machine_restart\n");
Not all devices using the gpio0/sys-led pin as a GPIO, configure the
pinmux. Add the necessary pinctrl properties to these devices to ensure
the pin is set up for use as GPIO.
Co-developed-by: INAGAKI Hiroshi
Signed-off-by: INAGAKI Hiroshi
Signed-off-by: Sander Vanheule
Tested-by: Bjørn Mork
Add a pinctrl-single node to manage the sys-led mux and JTAG mux.
This allows using the associated pins as GPIOs:
- sys-led: GPIO0
- JTAG: GPIO6, GPIO7, others unknown (TDO, TDI, TMS, TCK /TRST)
Suggested-by: Birger Koblitz
Signed-off-by: Sander Vanheule
---
On Tue, 2022-06-07 at 11:48 +0200, Sander Vanheule wrote:
> Add a pinctrl-single node to manage the sys-led mux and JTAG mux.
> This allows using the associated pins as GPIOs:
> - sys-led: GPIO0
> - JTAG: GPIO6, GPIO7, others unknown (TDO, TDI, TMS, TCK /TRST)
>
> Suggested-by: Birger Koblitz
From: Tomasz Maciej Nowak
Don't comence the switch to RAMFS when the image format is wrong. This
led to rebooting the device, which could lead to false impression that
upgrade succeded.
Being here, factor out the code responsible for upgrading RedBoot
devices to separate file.
Signed-off-by:
From: Tomasz Maciej Nowak
After the kernel has switched version to 5.10, JA76PF2 and
RouterStations lost the capability to sysupgrade the OpenWrt version.
The cause is the lack of porting the patches responsible for partial
flash erase block writing and these boards FIS directory and RedBoot
From: Tomasz Maciej Nowak
The bootloader on this board hid the partition containig MAC addresses
and prevented adding this space to FIS directory, therefore those had to
be stored in RedBoot configuration as aliases to be able to assigne them
to proper interfaces. Now that fixed partition size
From: Tomasz Maciej Nowak
Main changes revolve around changing the image format for devices which
share FIS directory and RedBoot config on same flash erase block and
cleanup following aftermath of this change.
Tomasz Maciej Nowak (7):
v2 -> v3
ath79: jj76pf2: enable TCN75 sensor
- none
From: Tomasz Maciej Nowak
The redboot-fis parser has option to specify the location of FIS
directory, use that, instead of patching the parser to scan for it, and
specifying location in kernel config.
Tested-by: Brian Gonyer
Signed-off-by: Tomasz Maciej Nowak
---
From: Tomasz Maciej Nowak
This image is supposed to be written with help of bootloader to the
flash, but as it stands, it's not aligned to block size and RedBoot will
happily create non-aligned partition size in FIS directory. This could
lead to kernel to mark the partition as read-only,
From: Tomasz Maciej Nowak
No reason to keep that around, since upstream one does the same.
Signed-off-by: Tomasz Maciej Nowak
---
.../ath79/dts/ar7161_adtran_bsap1880.dtsi | 2 +-
.../dts/bcm6348-inventel-livebox-1.dts| 2 +-
target/linux/gemini/image/Makefile| 4
From: Tomasz Maciej Nowak
This SBC has Microchip TCN75 sensor, wich measures ambient temperature.
Specify it in dts to allow readout by applications using kernel hwmon
API.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts | 13 +
35 matches
Mail list logo
