Re: Release goals for 22.XX

[Rosen Penev]

On Thu, Sep 30, 2021 at 1:05 PM Nick  wrote:
>
>
> On 9/30/21 21:43, Daniel Golle wrote:
> > On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
> >> On 30/09/2021 01:19, Nick wrote:
> >>> On 9/29/21 22:28, Hauke Mehrtens wrote:
> >>>
>  kernel 5.10:
>  We should get all targets to kernel 5.10. All targets which are not
>  on kernel 5.10 when we branch off should get removed.
> >>> Kernel 5.15 could be also a LTS Kernel that should be released in the
> >>> end of October? Why not aiming for it if we plan to release in 2022?
> >> This would undoubtedly delay the next release, as we've seen in the
> >> past. We don't even have all targets on 5.10, which was released roughly
> >> 9 months ago. You do the math. If we target 5.15, I doubt we'll even see
> >> a release in 2022.
> > I also believe we should do the next release based on Linux 5.10 and
> > try branching still this year (which I believe is realistic to make all
> > targets build with 5.10 till then), so we can target April 2022 as time
> > of release.
> Sounds good, so we can go on with 5.15 when it is released?
> I think the most problematic thing is if we want to have DSA support for
> all targets as requirement. Not sure if this is possible.
Don't think so. I think some platforms will get DSA.
>
> Bests
> Nick
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Rich Brown]

(I'm cc'ing both openwrt-devel and openwrt-adm since both will be involved in 
the decision)

> On Sep 29, 2021, at 4:28 PM, Hauke Mehrtens  wrote:
> 
> The OpenWrt 21.02 release is done and we should plan the next release.
> We already talked about this in the last meeting, see 
> https://openwrt.org/meetings/20210920
> 
> To monitor the current state I created this wiki page based on the wiki page 
> from the previous release:
> https://openwrt.org/docs/guide-developer/releases/goals/22.xx

Thanks for creating this page. If I understand it correctly, we are talking 
about:

1. All targets to kernel 5.10 (I think we said we'd drop support for those that 
cannot move to 5.10)
2. Import/backport mac80211 from the 5.15 kernel
3. GCC 11.2 & musl 1.2.x (done)
4. Switch to firewall4 by default
5. Switch lantiq target to DSA (done)
6. (Minor? No?) changes to LuCI
7. Nothing else

Questions:

- Is this a correct summary of what we're talking about for the next release?

- Could we accomplish all this by year-end? Who would be over-burdened by 
choosing that target date?

- If this is feasible, we could branch in January, with a generous time for 
several RC's, with a plan to ship 22.03 in March.

- What (if anything) would be left out if we "only did this"?

Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Paul Spooren]

On 9/30/21 10:01, Nick wrote:


On 9/30/21 21:43, Daniel Golle wrote:

On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:

On 30/09/2021 01:19, Nick wrote:

On 9/29/21 22:28, Hauke Mehrtens wrote:


kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not
on kernel 5.10 when we branch off should get removed.

Kernel 5.15 could be also a LTS Kernel that should be released in the
end of October? Why not aiming for it if we plan to release in 2022?

This would undoubtedly delay the next release, as we've seen in the
past. We don't even have all targets on 5.10, which was released 
roughly
9 months ago. You do the math. If we target 5.15, I doubt we'll even 
see

a release in 2022.

I also believe we should do the next release based on Linux 5.10 and
try branching still this year (which I believe is realistic to make all
targets build with 5.10 till then), so we can target April 2022 as time
of release.

Sounds good, so we can go on with 5.15 when it is released?


Some targets already moved to 5.10 as default, feel free to add 5.15 as 
the new TESTING kernel there.


I think the most problematic thing is if we want to have DSA support 
for all targets as requirement. Not sure if this is possible.


It seems fine found a okay'ish middle ground between DSA and non-DSA, so 
I'd not make DSA blocking for the next release but continue to integrate 
it where ever possible (and stable).


Paul


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

couldplug happening before modules.d

[Luiz Angelo Daros de Luca]

Hello,

I'm trying to mount a USB storage device using hotplug.d/block.
However, it never works during boot because "hotplug.d/block" is
triggered before modules.d are loaded. It only works if the filesystem
was already loaded by modules-boot.d (normally ext4).

I'm manually loading all fs modules before "mount" with something like:

for fsmods in /etc/modules.d/*-fs-*; do
while read -r fsmod; do
modprobe $fsmod
done <$fsmods
done
mount ...

But shouldn't it work "by design"?

It used to work in the past, maybe in the "18.06 era".

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Nick]

On 9/30/21 21:43, Daniel Golle wrote:

On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:

On 30/09/2021 01:19, Nick wrote:

On 9/29/21 22:28, Hauke Mehrtens wrote:


kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not
on kernel 5.10 when we branch off should get removed.

Kernel 5.15 could be also a LTS Kernel that should be released in the
end of October? Why not aiming for it if we plan to release in 2022?

This would undoubtedly delay the next release, as we've seen in the
past. We don't even have all targets on 5.10, which was released roughly
9 months ago. You do the math. If we target 5.15, I doubt we'll even see
a release in 2022.

I also believe we should do the next release based on Linux 5.10 and
try branching still this year (which I believe is realistic to make all
targets build with 5.10 till then), so we can target April 2022 as time
of release.

Sounds good, so we can go on with 5.15 when it is released?
I think the most problematic thing is if we want to have DSA support for 
all targets as requirement. Not sure if this is possible.


Bests
Nick

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Daniel Golle]

On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
> On 30/09/2021 01:19, Nick wrote:
> > On 9/29/21 22:28, Hauke Mehrtens wrote:
> >
> >> kernel 5.10:
> >> We should get all targets to kernel 5.10. All targets which are not
> >> on kernel 5.10 when we branch off should get removed.
> > Kernel 5.15 could be also a LTS Kernel that should be released in the
> > end of October? Why not aiming for it if we plan to release in 2022?
> 
> This would undoubtedly delay the next release, as we've seen in the
> past. We don't even have all targets on 5.10, which was released roughly
> 9 months ago. You do the math. If we target 5.15, I doubt we'll even see
> a release in 2022.

I also believe we should do the next release based on Linux 5.10 and
try branching still this year (which I believe is realistic to make all
targets build with 5.10 till then), so we can target April 2022 as time
of release.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Stijn Tintel]

On 30/09/2021 01:19, Nick wrote:
> On 9/29/21 22:28, Hauke Mehrtens wrote:
>
>> kernel 5.10:
>> We should get all targets to kernel 5.10. All targets which are not
>> on kernel 5.10 when we branch off should get removed.
> Kernel 5.15 could be also a LTS Kernel that should be released in the
> end of October? Why not aiming for it if we plan to release in 2022?

This would undoubtedly delay the next release, as we've seen in the
past. We don't even have all targets on 5.10, which was released roughly
9 months ago. You do the math. If we target 5.15, I doubt we'll even see
a release in 2022.

Stijn


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] realtek: ensure output drivers are enabled in RTL8231

[Sander Vanheule]

Hi Paul,

Thanks for the update, looks good to me.

On Thu, 2021-09-30 at 20:15 +0300, Paul Fertser wrote:
> The bootloader can leave the GPIO expander in a state which doesn't have
> output drivers enabled so GPIOs will properly work for input but output
> operations will have no effect.
> 
> To avoid disrupting the boot in case the bootloader left direction and
> data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
> reconfigure everything as input.
> 
> Signed-off-by: Paul Fertser 

Reviewed-by: Sander Vanheule 

Best,
Sander



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 22.XX

[Michael Richardson]

Rich Brown  wrote:
> - Having a firm feature freeze date decreases stress. If a particular
> feature is done/substantially working, it goes in. If it's not quite
> ready, it can skip this release, and get into the next release. (The
> alternative is what I think happened with DSA. It was a big change:
> there were a large number of problems that took a long time to iron
> out. That kept pushing out the date...)

I think you are bang on here.
And it needs to be socially acceptable to skip.
And yet the release is the forcing function.

In order to get things sorted for things like DSA,  in an ideal world it
would be a choice of two different packages.  The safe one as the default,
and the unstable one as a patch.
Of course, that's hard to do for many things.

In working backwards on dates, identifying the things that might be a
problem and having a "developer beta" from an easily rebased branch
would help for stuff like DSA.

> - Customers (our users, our industry partners) gain confidence in
> projects that can meet their deadlines. Imre noted that "industry is
> using the snapshots..." but I suspect the extended schedule just
> worries other vendors.



signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Possible difficulties at openwrt.org sites due to Letsencrypt root certificate expiration today...

[Hannu Nyman]

Heads up:

Forum has several reports that downloads.openwrt.org now fails in 21.02.0 and 
master due to invalid certificate.


Possibly related to the letsencrypt's old root certificate expiring today 

Or wolfssl not liking the remaining root cert?


https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

See

https://forum.openwrt.org/t/2hrs-ago-all-openwrt-agents-stopped-cert-verify-failed-badcert-expired/107889/6

https://forum.openwrt.org/t/opkg-update-problem-invalid-ssl-certificate/107895

https://forum.openwrt.org/t/opkg-uclient-fetch-cant-download-from-https-site-invalid-ssl-certificate/107891



(For me, downloads from master with openssl-based wget seem to work normally)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm27xx: add RPI_AXIPERF symbol

[Stijn Tintel]

When KERNEL_PERF_EVENTS is enabled in OpenWrt, or PERF_EVENTS in the
kernel config, the RPI_AXIPERF is exposed. Add it to the subtarget
kernel configs to avoid build failures.

Signed-off-by: Stijn Tintel 
---
 target/linux/bcm27xx/bcm2708/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2708/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2709/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2709/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2710/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2710/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2711/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2711/config-5.4  | 1 +
 8 files changed, 8 insertions(+)

diff --git a/target/linux/bcm27xx/bcm2708/config-5.10 
b/target/linux/bcm27xx/bcm2708/config-5.10
index 12567abb24..8e8ae51443 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.10
+++ b/target/linux/bcm27xx/bcm2708/config-5.10
@@ -302,6 +302,7 @@ CONFIG_RESET_CONTROLLER=y
 # CONFIG_RESET_RASPBERRYPI is not set
 CONFIG_RESET_SIMPLE=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 # CONFIG_RPI_POE_POWER is not set
 CONFIG_SCSI=y
 # CONFIG_SCSI_LOWLEVEL is not set
diff --git a/target/linux/bcm27xx/bcm2708/config-5.4 
b/target/linux/bcm27xx/bcm2708/config-5.4
index 42203d2587..ea68858483 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.4
+++ b/target/linux/bcm27xx/bcm2708/config-5.4
@@ -292,6 +292,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_RESET_CONTROLLER=y
 CONFIG_RESET_SIMPLE=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 CONFIG_SCSI=y
 # CONFIG_SCSI_LOWLEVEL is not set
 # CONFIG_SCSI_PROC_FS is not set
diff --git a/target/linux/bcm27xx/bcm2709/config-5.10 
b/target/linux/bcm27xx/bcm2709/config-5.10
index 3986cffec2..928f17c974 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.10
+++ b/target/linux/bcm27xx/bcm2709/config-5.10
@@ -379,6 +379,7 @@ CONFIG_RESET_RASPBERRYPI=y
 CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 # CONFIG_RPI_POE_POWER is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
diff --git a/target/linux/bcm27xx/bcm2709/config-5.4 
b/target/linux/bcm27xx/bcm2709/config-5.4
index 4392674371..4e4ef63ad0 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.4
+++ b/target/linux/bcm27xx/bcm2709/config-5.4
@@ -378,6 +378,7 @@ CONFIG_RESET_CONTROLLER=y
 CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
 CONFIG_SCSI=y
diff --git a/target/linux/bcm27xx/bcm2710/config-5.10 
b/target/linux/bcm27xx/bcm2710/config-5.10
index 4d111eb4c5..3c4c46f85a 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.10
+++ b/target/linux/bcm27xx/bcm2710/config-5.10
@@ -371,6 +371,7 @@ CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 # CONFIG_RPI_POE_POWER is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
diff --git a/target/linux/bcm27xx/bcm2710/config-5.4 
b/target/linux/bcm27xx/bcm2710/config-5.4
index 201b6fc2d6..b79c20fc89 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.4
+++ b/target/linux/bcm27xx/bcm2710/config-5.4
@@ -375,6 +375,7 @@ CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
 CONFIG_SCSI=y
diff --git a/target/linux/bcm27xx/bcm2711/config-5.10 
b/target/linux/bcm27xx/bcm2711/config-5.10
index 77254279ea..188d5a41ec 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.10
+++ b/target/linux/bcm27xx/bcm2711/config-5.10
@@ -383,6 +383,7 @@ CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 # CONFIG_RPI_POE_POWER is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
diff --git a/target/linux/bcm27xx/bcm2711/config-5.4 
b/target/linux/bcm27xx/bcm2711/config-5.4
index 25af3338eb..258f29989f 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.4
+++ b/target/linux/bcm27xx/bcm2711/config-5.4
@@ -387,6 +387,7 @@ CONFIG_RESET_SIMPLE=y
 CONFIG_RFS_ACCEL=y
 CONFIG_RODATA_FULL_DEFAULT_ENABLED=y
 # CONFIG_RPIVID_MEM is not set
+# CONFIG_RPI_AXIPERF is not set
 CONFIG_RPS=y
 CONFIG_RWSEM_SPIN_ON_OWNER=y
 CONFIG_SCSI=y
-- 
2.32.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] bcm27xx: add SND_SOC_AD193X_SPI to kernel configs

[Stijn Tintel]

On 30/09/2021 19:58, Stijn Tintel wrote:
> When building an image for the bcm27xx target, some combinations of
> config options will fail to build due the SND_SOC_AD193X_SPI kernel
> config symbol being missing.
>
> The problem only occurs on bcm27xx as the target contains a patch that
> modifies the Kconfig file containing the symbol. In the vanilla kernel,
> there is no string after the TRISTATE keyword so the symbol is not
> exposed.
>
> The symbol depends on SPI_MASTER, which is exposed by either
> kmod-mmc-spi, kmod-spi-bitbang, kmod-spi-dev, kmod-spi-bcm2835 or
> kmod-spi-bcm2835-aux. It is defined in thesound/soc/codecs directory,
> which is only included when SND_SOC is enabled, so this problem doesn't
> occur when kmod-sound-soc-core is not enabled. As the
> kmod-sound-soc-bcm2835-i2s package disables the SND_SOC_AD193X_SPI
> symbol, it also doesn't occur when kmod-sound-soc-bcm2835-i2s is
> enabled.
>
> As there are several possible config combinations that do exhibit this
> problem, it is best to solve it by adding the missing symbol to the
> subtarget kernel configs. By doing this we can remove it from the
> kmod-sound-soc-bcm2835-i2s package.

Please disregard, this is incomplete.

Stijn


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm27xx: add SND_SOC_AD193X_{I2C,SPI} symbols

[Stijn Tintel]

When building an image for the bcm27xx target, some combinations of
config options will fail to build due the SND_SOC_AD193X_I2C and
SND_SOC_AD193X_SPI kernel config symbols being missing.

The problem only occurs on bcm27xx as the target contains a patch that
modifies the Kconfig file containing the symbols; in the vanilla kernel,
there is no string after the tristate keyword so the symbol is not
exposed.

The _I2C symbol depends on I2C, which is enabled in the kernel configs
of all bcm27xx subtargets.

The _SPI symbol depends on SPI_MASTER, which is exposed by either
kmod-mmc-spi, kmod-spi-bitbang, kmod-spi-dev, kmod-spi-bcm2835 or
kmod-spi-bcm2835-aux.

Both symbols are defined in the sound/soc/codecs directory, which is
only included when SND_SOC is enabled, so this problem doesn't occur
when kmod-sound-soc-core is not enabled. As the
kmod-sound-soc-bcm2835-i2s package disables the SND_SOC_AD193X_SPI
symbol, it also doesn't occur when kmod-sound-soc-bcm2835-i2s is
enabled.

As there are several possible config combinations that do exhibit this
problem, it is best to solve it by adding the missing symbols to the
subtarget kernel configs. By doing this we can remove them from the
kmod-sound-soc-bcm2835-i2s package.

Signed-off-by: Stijn Tintel 
---
 target/linux/bcm27xx/bcm2708/config-5.10 | 2 ++
 target/linux/bcm27xx/bcm2708/config-5.4  | 2 ++
 target/linux/bcm27xx/bcm2709/config-5.10 | 2 ++
 target/linux/bcm27xx/bcm2709/config-5.4  | 2 ++
 target/linux/bcm27xx/bcm2710/config-5.10 | 2 ++
 target/linux/bcm27xx/bcm2710/config-5.4  | 2 ++
 target/linux/bcm27xx/bcm2711/config-5.10 | 2 ++
 target/linux/bcm27xx/bcm2711/config-5.4  | 2 ++
 target/linux/bcm27xx/modules/sound.mk| 2 --
 9 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/target/linux/bcm27xx/bcm2708/config-5.10 
b/target/linux/bcm27xx/bcm2708/config-5.10
index 094765abdc..12567abb24 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.10
+++ b/target/linux/bcm27xx/bcm2708/config-5.10
@@ -321,6 +321,8 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2708/config-5.4 
b/target/linux/bcm27xx/bcm2708/config-5.4
index ef71076497..42203d2587 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.4
+++ b/target/linux/bcm27xx/bcm2708/config-5.4
@@ -309,6 +309,8 @@ CONFIG_SERIAL_DEV_BUS=y
 CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2709/config-5.10 
b/target/linux/bcm27xx/bcm2709/config-5.10
index 5b6c8b7edd..3986cffec2 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.10
+++ b/target/linux/bcm27xx/bcm2709/config-5.10
@@ -402,6 +402,8 @@ CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMP_ON_UP=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2709/config-5.4 
b/target/linux/bcm27xx/bcm2709/config-5.4
index 4118d0f684..4392674371 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.4
+++ b/target/linux/bcm27xx/bcm2709/config-5.4
@@ -399,6 +399,8 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMP_ON_UP=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2710/config-5.10 
b/target/linux/bcm27xx/bcm2710/config-5.10
index 39818dabac..4d111eb4c5 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.10
+++ b/target/linux/bcm27xx/bcm2710/config-5.10
@@ -393,6 +393,8 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSEMEM=y
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_SPARSEMEM_MANUAL=y
diff --git a/target/linux/bcm27xx/bcm2710/config-5.4 
b/target/linux/bcm27xx/bcm2710/config-5.4
index 1ad066e0d7..201b6fc2d6 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.4
+++ b/target/linux/bcm27xx/bcm2710/config-5.4
@@ -395,6 +395,8 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
+# CONFIG_SND_SOC_AD193X_I2C is not set
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSEMEM=y
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_SPARSEMEM_MANUAL=y
diff --git a/target/linux/bcm27xx/bcm2711/config-5.10 
b/target/linux/bcm27xx/bcm2711/config-5.10
index df7721107a..77254279ea 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.10
+++ b/target/linux/bcm27xx/bcm2711/config-5.10
@@ -404,6 +404,8 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 

[PATCH v2] realtek: ensure output drivers are enabled in RTL8231

[Paul Fertser]

The bootloader can leave the GPIO expander in a state which doesn't have
output drivers enabled so GPIOs will properly work for input but output
operations will have no effect.

To avoid disrupting the boot in case the bootloader left direction and
data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
reconfigure everything as input.

Signed-off-by: Paul Fertser 
---

Notes:
Changes from v1:
 - Fix comment to mention we affect two extra GPIOs
 - Remove unused "v" declaration.

 .../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c| 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c 
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int 
offset, int value)
 
 int rtl8231_init(struct rtl8231_gpios *gpios)
 {
-   u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
 
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
 
-   /* Select GPIO functionality for pins 0-34 */
+   /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+   rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
-   v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
-   rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+   rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+   rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+   /* Set LED_Start to enable drivers for output mode */
+   rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
 
return 0;
 }
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm27xx: add SND_SOC_AD193X_SPI to kernel configs

[Stijn Tintel]

When building an image for the bcm27xx target, some combinations of
config options will fail to build due the SND_SOC_AD193X_SPI kernel
config symbol being missing.

The problem only occurs on bcm27xx as the target contains a patch that
modifies the Kconfig file containing the symbol. In the vanilla kernel,
there is no string after the TRISTATE keyword so the symbol is not
exposed.

The symbol depends on SPI_MASTER, which is exposed by either
kmod-mmc-spi, kmod-spi-bitbang, kmod-spi-dev, kmod-spi-bcm2835 or
kmod-spi-bcm2835-aux. It is defined in thesound/soc/codecs directory,
which is only included when SND_SOC is enabled, so this problem doesn't
occur when kmod-sound-soc-core is not enabled. As the
kmod-sound-soc-bcm2835-i2s package disables the SND_SOC_AD193X_SPI
symbol, it also doesn't occur when kmod-sound-soc-bcm2835-i2s is
enabled.

As there are several possible config combinations that do exhibit this
problem, it is best to solve it by adding the missing symbol to the
subtarget kernel configs. By doing this we can remove it from the
kmod-sound-soc-bcm2835-i2s package.

Signed-off-by: Stijn Tintel 
---
 target/linux/bcm27xx/bcm2708/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2708/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2709/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2709/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2710/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2710/config-5.4  | 1 +
 target/linux/bcm27xx/bcm2711/config-5.10 | 1 +
 target/linux/bcm27xx/bcm2711/config-5.4  | 1 +
 target/linux/bcm27xx/modules/sound.mk| 1 -
 9 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/linux/bcm27xx/bcm2708/config-5.10 
b/target/linux/bcm27xx/bcm2708/config-5.10
index 094765abdc..f49984ba8a 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.10
+++ b/target/linux/bcm27xx/bcm2708/config-5.10
@@ -321,6 +321,7 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2708/config-5.4 
b/target/linux/bcm27xx/bcm2708/config-5.4
index ef71076497..7ff6df894f 100644
--- a/target/linux/bcm27xx/bcm2708/config-5.4
+++ b/target/linux/bcm27xx/bcm2708/config-5.4
@@ -309,6 +309,7 @@ CONFIG_SERIAL_DEV_BUS=y
 CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2709/config-5.10 
b/target/linux/bcm27xx/bcm2709/config-5.10
index 5b6c8b7edd..b441e1f0df 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.10
+++ b/target/linux/bcm27xx/bcm2709/config-5.10
@@ -402,6 +402,7 @@ CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMP_ON_UP=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2709/config-5.4 
b/target/linux/bcm27xx/bcm2709/config-5.4
index 4118d0f684..bd2fae45d2 100644
--- a/target/linux/bcm27xx/bcm2709/config-5.4
+++ b/target/linux/bcm27xx/bcm2709/config-5.4
@@ -399,6 +399,7 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMP_ON_UP=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SRCU=y
 # CONFIG_STRIP_ASM_SYMS is not set
diff --git a/target/linux/bcm27xx/bcm2710/config-5.10 
b/target/linux/bcm27xx/bcm2710/config-5.10
index 39818dabac..ff62955591 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.10
+++ b/target/linux/bcm27xx/bcm2710/config-5.10
@@ -393,6 +393,7 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
 CONFIG_SMSC_PHY=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSEMEM=y
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_SPARSEMEM_MANUAL=y
diff --git a/target/linux/bcm27xx/bcm2710/config-5.4 
b/target/linux/bcm27xx/bcm2710/config-5.4
index 1ad066e0d7..fc92df47f4 100644
--- a/target/linux/bcm27xx/bcm2710/config-5.4
+++ b/target/linux/bcm27xx/bcm2710/config-5.4
@@ -395,6 +395,7 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSEMEM=y
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_SPARSEMEM_MANUAL=y
diff --git a/target/linux/bcm27xx/bcm2711/config-5.10 
b/target/linux/bcm27xx/bcm2711/config-5.10
index df7721107a..e20007654b 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.10
+++ b/target/linux/bcm27xx/bcm2711/config-5.10
@@ -404,6 +404,7 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SG_POOL=y
 CONFIG_SMP=y
+# CONFIG_SND_SOC_AD193X_SPI is not set
 CONFIG_SPARSEMEM=y
 CONFIG_SPARSEMEM_EXTREME=y
 CONFIG_SPARSEMEM_MANUAL=y
diff --git a/target/linux/bcm27xx/bcm2711/config-5.4 
b/target/linux/bcm27xx/bcm2711/config-5.4
index 89d087fa9e..7ccadbbaaf 100644
--- a/target/linux/bcm27xx/bcm2711/config-5.4
+++ b/target/linux/bcm27xx/bcm2711/config-5.4
@@ -407,6 +407,7 @@ CONFIG_SERIAL_MCTRL_GPIO=y
 

Re: [PATCH] bcm53xx: disable CONFIG_SWCONFIG_B53_PHY_DRIVER

[Rafał Miłecki]

Cc Tobias, author of the 8f9cd1af0f9c ("swconfig: fix Broadcom b53 support").

Another option would be to revert above commit (.of_match_table part anyway).

On 30.09.2021 16:40, Rafał Miłecki wrote:

From: Rafał Miłecki 

OpenWrt downstream b53 MDIO driver is bugged as it:
1. Registers as PHY device driver (while switch is an MDIO device)
2. Provides of_match_table

That results in bypassing kernel bus matching checks and probing b53 for
MDIO device treated as PHY device. It doesn't work as PHY structure
isn't initialized and phy_probe() causes a softlock.

This happened to work with kernel 5.4 but some internal change revealed
that broken design.

For bcm53xx this shouldn't be critical as only Linksys EA9500 extra
switch is connected using MDIO.

Signed-off-by: Rafał Miłecki 
---
  target/linux/bcm53xx/config-5.10 | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/bcm53xx/config-5.10 b/target/linux/bcm53xx/config-5.10
index 9d98e812bd..e495419aad 100644
--- a/target/linux/bcm53xx/config-5.10
+++ b/target/linux/bcm53xx/config-5.10
@@ -268,8 +268,7 @@ CONFIG_SPI_MEM=y
  CONFIG_SRCU=y
  CONFIG_SWCONFIG=y
  CONFIG_SWCONFIG_B53=y
-CONFIG_SWCONFIG_B53_PHY_DRIVER=y
-CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+# CONFIG_SWCONFIG_B53_PHY_DRIVER is not set
  CONFIG_SWCONFIG_B53_SRAB_DRIVER=y
  CONFIG_SWPHY=y
  CONFIG_SWP_EMULATE=y




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] bcm53xx: disable CONFIG_SWCONFIG_B53_PHY_DRIVER

[Rafał Miłecki]

From: Rafał Miłecki 

OpenWrt downstream b53 MDIO driver is bugged as it:
1. Registers as PHY device driver (while switch is an MDIO device)
2. Provides of_match_table

That results in bypassing kernel bus matching checks and probing b53 for
MDIO device treated as PHY device. It doesn't work as PHY structure
isn't initialized and phy_probe() causes a softlock.

This happened to work with kernel 5.4 but some internal change revealed
that broken design.

For bcm53xx this shouldn't be critical as only Linksys EA9500 extra
switch is connected using MDIO.

Signed-off-by: Rafał Miłecki 
---
 target/linux/bcm53xx/config-5.10 | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/bcm53xx/config-5.10 b/target/linux/bcm53xx/config-5.10
index 9d98e812bd..e495419aad 100644
--- a/target/linux/bcm53xx/config-5.10
+++ b/target/linux/bcm53xx/config-5.10
@@ -268,8 +268,7 @@ CONFIG_SPI_MEM=y
 CONFIG_SRCU=y
 CONFIG_SWCONFIG=y
 CONFIG_SWCONFIG_B53=y
-CONFIG_SWCONFIG_B53_PHY_DRIVER=y
-CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+# CONFIG_SWCONFIG_B53_PHY_DRIVER is not set
 CONFIG_SWCONFIG_B53_SRAB_DRIVER=y
 CONFIG_SWPHY=y
 CONFIG_SWP_EMULATE=y
-- 
2.26.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: initramfs for ACPI tables on x86

[Daniel Golle]

On Thu, Sep 30, 2021 at 02:49:57PM +0200, Florian Eckert wrote:
> Since the update of kernel from 5.4 to 5.10 in the openwrt master branch
> [1],
> I have problems with additional hardware on the I2C (SMBus) of my APU3.
> 
> The Linux upstream removed the platform data support for my I2C IO-Expander
> mcp23s08 [3].
> Because of this change I could not use my own written platform device
> specification anymore.
> 
> This is common for this kind of device on x86 which does not support
> device-tree.
> See for exaple the platform init on the x86 geode board.[5]
> 
> If the device supports ACPI, this is now the why to do this [6].
> I am still in the process of building the SSDT ACPI table for the i2c
> mcp23s08 device connect to the SMBus.
> 
> As I now know we could load these SSTD into the kernel during operation or
> via an initrd on boot.
> 
> As far as I have seen, no initrd is loaded during normal operation [4] on
> OpenWrt.
> 
> Is there any way to create an initrd to load the ACPI tables and then mount
> the initrd so the kernel can load this kind of files?
> What would this look like in OpenWrt?

I think it should be just as fine to load them early during boot,
ie. place a script in /lib/preinit/ which does that.

On boards with coreboot like the apu3 the best would probably be to
fix ACPI tables supplied by the BIOS (or swap SeaBIOS for an UEFI
implementation like Tianocore at the same time) instead of patching
things using Linux at runtime.


> 
> On other target we have the device-tree but on X86 this is not possible and
> we could only use ACPI for this kind of task.
> To do this the acpica package is needed to generate an SSDT [7]
> 
> The initramfs that are created now run completely in RAM and are intended
> for development purposes only.
> 
> Does anyone have any experience or has already deal with this topic of ACPI
> and inird in OpenWrt?
> I would be happy if someone shares their thoughts with me.
> 
> --
> Regards Florian
> 
> [1] 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/x86/Makefile;h=fbad527e0ac3239647a9d1eabcaf8fd751396973;hp=0ab322d8bc4fd31a75cb16dba8665b1db315398f;hb=64be0eadc17988f29d0a4b89569840d917746498;hpb=c9042202ad39e447a21afd91ec777bbc6cc8b72c
> [2] https://pcengines.ch/apu.htm
> [3] 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pinctrl/pinctrl-mcp23s08.c?h=v5.10.70=6aba6ed879b3471903c8ada28ba968a268df6143
> [4] 
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/image/grub-pc.cfg;hb=fa13dd658f59df41b9184d4dc15a5b29530e7c2c
> [5] 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/platform/geode/alix.c?h=v5.10.70
> [6] https://www.youtube.com/watch?v=nlKjUAv3RL0_channel=OSDNConf
> [7] https://github.com/openwrt/packages/pull/16775
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

initramfs for ACPI tables on x86

[Florian Eckert]

Since the update of kernel from 5.4 to 5.10 in the openwrt master branch 
[1],

I have problems with additional hardware on the I2C (SMBus) of my APU3.

The Linux upstream removed the platform data support for my I2C 
IO-Expander mcp23s08 [3].
Because of this change I could not use my own written platform device 
specification anymore.


This is common for this kind of device on x86 which does not support 
device-tree.

See for exaple the platform init on the x86 geode board.[5]

If the device supports ACPI, this is now the why to do this [6].
I am still in the process of building the SSDT ACPI table for the i2c 
mcp23s08 device connect to the SMBus.


As I now know we could load these SSTD into the kernel during operation 
or via an initrd on boot.


As far as I have seen, no initrd is loaded during normal operation [4] 
on OpenWrt.


Is there any way to create an initrd to load the ACPI tables and then 
mount the initrd so the kernel can load this kind of files?

What would this look like in OpenWrt?

On other target we have the device-tree but on X86 this is not possible 
and we could only use ACPI for this kind of task.

To do this the acpica package is needed to generate an SSDT [7]

The initramfs that are created now run completely in RAM and are 
intended for development purposes only.


Does anyone have any experience or has already deal with this topic of 
ACPI and inird in OpenWrt?

I would be happy if someone shares their thoughts with me.

--
Regards Florian

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/x86/Makefile;h=fbad527e0ac3239647a9d1eabcaf8fd751396973;hp=0ab322d8bc4fd31a75cb16dba8665b1db315398f;hb=64be0eadc17988f29d0a4b89569840d917746498;hpb=c9042202ad39e447a21afd91ec777bbc6cc8b72c

[2] https://pcengines.ch/apu.htm
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pinctrl/pinctrl-mcp23s08.c?h=v5.10.70=6aba6ed879b3471903c8ada28ba968a268df6143
[4] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/image/grub-pc.cfg;hb=fa13dd658f59df41b9184d4dc15a5b29530e7c2c
[5] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/platform/geode/alix.c?h=v5.10.70

[6] https://www.youtube.com/watch?v=nlKjUAv3RL0_channel=OSDNConf
[7] https://github.com/openwrt/packages/pull/16775

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Package : Crowdsec: Initial package v1.2.0 - #16244

[Gérald Kerma]

Héllo,

https://github.com/openwrt/packages/pull/16244

Is there any chance of integration ?

Thanks…
G.Kerma

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: use lzma-loader on D-Link DIR-615 H1

[Mirko Parthey]

Fixes the boot loader LZMA decompression issue:
LZMA ERROR 1 - must RESET board to recover

Signed-off-by: Mirko Parthey 
---
Please consider backporting to openwrt-21.02, which is also affected.

 target/linux/ramips/image/rt305x.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index 6c339dc..e817c12 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -433,6 +433,7 @@ endef
 TARGET_DEVICES += dlink_dir-615-d

 define Device/dlink_dir-615-h1
+  $(Device/uimage-lzma-loader)
   SOC := rt3352
   BLOCKSIZE := 4k
   IMAGES += factory.bin
--
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ensure output drivers are enabled in RTL8231

[Sander Vanheule]

Hi Paul,

On Wed, 2021-09-29 at 23:52 +0300, Paul Fertser wrote:
> The bootloader can leave the GPIO expander in a state which doesn't have
> output drivers enabled so GPIOs will properly work for input but output
> operations will have no effect.
> 
> To avoid disrupting the boot in case the bootloader left direction and
> data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
> reconfigure everything as input.
> 
> Thanks to Sander Vanheule for telling about LED_Start.
> 
> Signed-off-by: Paul Fertser 
> ---
> 
> My previous patch to this part of the code is marked Accepted in the
> Patchwork so this one is on top of it. Feel free to squash them
> together.

Already merged in commit 16ae56b4f9ec.

> 
>  .../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c  | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> index a8ffcdc31368..405c2c151368 100644
> --- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> +++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> @@ -254,11 +254,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
> sw_w32_mask(3, 1, RTL838X_DMY_REG5);
> }
>  
> -   /* Select GPIO functionality for pins 0-34 */
> +   /* Select GPIO functionality and force input direction for pins 0-34

You're now really configuring all 37 GPIOs, so the pin range in the comment
isn't quite correct any more.

> */
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
> +   rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
> -   v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
> -   rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);

The previous patch added this variable 'v' for the RMW operation. I assume you
can now remove that variable's declaration too?

> +   rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
> +   rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
> +
> +   /* Set LED_Start to enable drivers for output mode */
> +   rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);

Unless you wanted to do a RMW to preserve the other bits in LED_FUNC0. Not that
it would make much of a difference, since the only other field that is changed
to a non-default value is En_bicolor (i.e. changing the LED matrix layout, which
isn't used anyway).

Best,
Sander


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel