[LEDE-DEV] [lede] Patch notification: 1 patch updated
Hello, The following patch (submitted by you) has been updated in patchwork: * lede: [LEDE-DEV,1/2] firmware: add firmware for rtl8821ae support - http://patchwork.ozlabs.org/patch/764814/ - for: LEDE development was: New now: Accepted This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the patchwork system at patchwork.ozlabs.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.ozlabs.org/mail/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Problem with console without console=ttyS0 bootarg
On 14 March 2017 at 07:37, Rafał Miłecki wrote:
> My current DTS file contains following entry:
> bootargs = "console=ttyS0,115200"
> and it works in a following way:
>
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [9.320212] procd: - early -
> [9.323174] procd: - watchdog -
> [9.924724] procd: - ubus -
> [9.986055] procd: - init -
> Please press Enter to activate this console.
> === WARNING! =
> There is no root password defined on this device!
> Use the "passwd" command to set up a new password
> in order to prevent unauthorized SSH logins.
> --
> root@LEDE:/#
>
>
>
> If I enable "ttylogin" in /etc/config/system it works quite similarly (just
> asks for a login):
>
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [9.362481] procd: - early -
> [9.365550] procd: - watchdog -
> [9.983522] procd: - ubus -
> [ 10.044877] procd: - init -
> Please press Enter to activate this console.
> LEDE login:
> LEDE login: root
> === WARNING! =
> There is no root password defined on this device!
> Use the "passwd" command to set up a new password
> in order to prevent unauthorized SSH logins.
> --
> root@LEDE:~#
>
>
> My problem appears when I drop bootargs and use:
> stdout-path = "/chipcommonA/serial@0300:115200";
> instead (which is a non-deprecated DTS solution).
> In such case I can't login anymore:
>
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [9.340180] procd: - early -
> [9.343141] procd: - watchdog -
> [9.944758] procd: - ubus -
> [ 10.006092] procd: - init -
>
>
> Do you know what's the reason for this? Can we have a proper console support
> while using upstream preferred syntax for the stdout-path?
> Please note entering failsafe mode it not affected by this.
Since noone got idea how to handle this, I added workaround as for now
in commit 0a05fbd135663 ("bcm53xx: add support for TP-LINK Archer C5
V2")
https://git.lede-project.org/?p=source.git;a=commit;h=0a05fbd1356631a1f903adcd63ffb05550537667
You can find it in the 320-ARM-dts-BCM5301X-Add-serial-to-the-bootargs.patch
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Problem with commit "kernel: add hwmon for W83627EHF and family"
> On May 21, 2017, at 10:03 AM, Daniel Golle wrote:
>
> Hi Rafal,
>
> On Sun, May 21, 2017 at 05:02:44PM +0200, Rafał Miłecki wrote:
>> Hi,
>>
>> I noticed commit 0dcc36fc7ddec ("kernel: add hwmon for W83627EHF and
>> family") in the LEDE tree that doesn't look OK to me.
>>
>> 1) Package for hwmon-w83627ehf
>> Do we need it to be a package? Or could it be built-in into the kernel?
>> Do we need it to be a global package? Usually hwmon drivers are
>> designed for a specific device and it should be enough to have it in
>> target/linux/*/modules.mk
>
> True, but all other x86-specific hwmon modules are in
> package/kernel/linux/modules as well and I'd rather wanted it to be
> consistent.
>
>>
>> 2) 800-hwmon-w83627ehf-dont-claim-nct677x.patch
>> I really don't like this one as it's totally unclear why we need this
>> change. What's wrong with NCT6775 and the w83627ehf driver? It should
>> be well described in the patch.
>
> Sorry for the lack of a more detailed description.
> The problem here is that the W83627EHF driver also claims the NCT677x
> hardware but doesn't support all features (according to
> Philip Prindeville). I reckon he can provide more information regarding
> which features which are available when using the nct6776 driver are
> missing in the w83627ehf driver on NCT677x hardware.
>
> Cheers
>
> Daniel
To follow up on what Daniel said, yes, the older w83627 has a subset of
functionality for the nct6775 chips, but the native nct6775 driver does a
better job.
Quoting Documentation/hwmon/nct6775:
Note
This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
driver.
and drivers/hwmon/Kconfig:
config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
depends on !PPC
select HWMON_VID
help
If you say yes here you get support for the hardware monitoring
functionality of the Nuvoton NCT6106D, NCT6775F, NCT6776F, NCT6779D,
NCT6791D, NCT6792D, NCT6793D, and compatible Super-I/O chips. This
driver replaces the w83627ehf driver for NCT6775F and NCT6776F.
This driver can also be built as a module. If so, the module
will be called nct6775.
...
config SENSORS_W83627EHF
tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG, NCT6775F, NCT6776F"
depends on !PPC
select HWMON_VID
help
If you say yes here you get support for the hardware
monitoring functionality of the Winbond W83627EHF Super-I/O chip.
This driver also supports the W83627EHG, which is the lead-free
version of the W83627EHF, and the W83627DHG, which is a similar
chip suited for specific Intel processors that use PECI such as
the Core 2 Duo. And also the W83627UHG, which is a stripped down
version of the W83627DHG (as far as hardware monitoring goes.)
This driver also supports Nuvoton W83667HG, W83667HG-B, NCT6775F
(also known as W83667HG-I), and NCT6776F.
This driver can also be built as a module. If so, the module
will be called w83627ehf.
If you definitely have NCT6775F hardware, they you don’t want to build both
drivers into your kernel.
If you want to build a kernel that supports both the NCT6775 and W83627HF
drivers, then you need this patch so that ONLY the NCT6775 will detect the
chipset.
It’s not clear why a few of the patches to add partial NCT6775 support to the
W83627HF driver weren’t backed out after the NCT6775 driver was merged…
probably an oversight.
-Philip
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Problem with commit "kernel: add hwmon for W83627EHF and family"
Hi Rafal,
On Sun, May 21, 2017 at 05:02:44PM +0200, Rafał Miłecki wrote:
> Hi,
>
> I noticed commit 0dcc36fc7ddec ("kernel: add hwmon for W83627EHF and
> family") in the LEDE tree that doesn't look OK to me.
>
> 1) Package for hwmon-w83627ehf
> Do we need it to be a package? Or could it be built-in into the kernel?
> Do we need it to be a global package? Usually hwmon drivers are
> designed for a specific device and it should be enough to have it in
> target/linux/*/modules.mk
True, but all other x86-specific hwmon modules are in
package/kernel/linux/modules as well and I'd rather wanted it to be
consistent.
>
> 2) 800-hwmon-w83627ehf-dont-claim-nct677x.patch
> I really don't like this one as it's totally unclear why we need this
> change. What's wrong with NCT6775 and the w83627ehf driver? It should
> be well described in the patch.
Sorry for the lack of a more detailed description.
The problem here is that the W83627EHF driver also claims the NCT677x
hardware but doesn't support all features (according to
Philip Prindeville). I reckon he can provide more information regarding
which features which are available when using the nct6776 driver are
missing in the w83627ehf driver on NCT677x hardware.
Cheers
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
Ralph, Am 21.05.2017 um 14:23 schrieb Ralph Sennhauser: > If the seeded ubifs could be generalized to snapshot support ala btrfs > that would change things a lot as it would enable uses far beyond just > factory reset. No idea how feasible that is but might be worth > considering instead. I thought about that too but this requires much more invasive changes in UBIFS. So I'm not sure whether it is worth the hassle. Thanks, //richard ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Problem with commit "kernel: add hwmon for W83627EHF and family"
Hi,
I noticed commit 0dcc36fc7ddec ("kernel: add hwmon for W83627EHF and
family") in the LEDE tree that doesn't look OK to me.
1) Package for hwmon-w83627ehf
Do we need it to be a package? Or could it be built-in into the kernel?
Do we need it to be a global package? Usually hwmon drivers are
designed for a specific device and it should be enough to have it in
target/linux/*/modules.mk
2) 800-hwmon-w83627ehf-dont-claim-nct677x.patch
I really don't like this one as it's totally unclear why we need this
change. What's wrong with NCT6775 and the w83627ehf driver? It should
be well described in the patch.
--
Rafał
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] CPU locked at lowest frequency on BCM2078 targets
> Hi, thanks for pointing that out. > > Can we get cpufreq, ondemand scaler, and default=ondemand for this > > platform / two targets? If needed I can submit a patch / signoff, or > > if there is a reason this should not be done I'd love to start a > > discussion about it. > Please test a build from my staging tree: > https://git.lede-project.org/?p=lede/stintel/staging.git;a=summary > Sorry for the delay in responding as I was on vacation last week. I just pulled your staging and built new clean images. Works perfectly on all 3 targets: bcm2708 (RPi0W) and bcm2709/bcm2710 (Pi3). Time in state and transition stats appear to track properly as well. Looks good! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
Hi Richard On Sun, 21 May 2017 10:40:05 +0200 Richard Weinberger wrote: > Geert, > > Am 21.05.2017 um 10:37 schrieb Geert Uytterhoeven: > > On Sat, May 20, 2017 at 9:36 PM, Ralph Sennhauser > > wrote: > >> There is also the size consideration. Unless a seeded ubifs can get > >> close to squashfs in terms of compression there would still be a > >> use-case for squashfs with an ubifs overlay. My current root as > >> ubifs instead of squashfs is 76.8% bigger. > > > > As seeded files are stored and kept unmodified, they could be > > stored in compressed form? > > This is what UBIFS already does. Right, or it would be some 400-500% difference. Another advantage of the squashfs with overlay came to mind. OpenWrt doesn't do a factory reset per se but boots into a "failsafe" mode which just doesn't mount the overlay. This allows to fix the overlay (some screwed up config value which prevents connection) or to reset the password for example without having to reinstall packages and reconfigure the device from ground up. Wiping the overlay is basically the last resort. With the expectation distributions to use the same approach for as many devices possible I see the seeded ubifs running out of users fast. Some commercial vendor backporting it to a 3.10 kernel maybe? If the seeded ubifs could be generalized to snapshot support ala btrfs that would change things a lot as it would enable uses far beyond just factory reset. No idea how feasible that is but might be worth considering instead. Ralph > > Thanks, > //richard ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
Geert, Am 21.05.2017 um 10:37 schrieb Geert Uytterhoeven: > On Sat, May 20, 2017 at 9:36 PM, Ralph Sennhauser > wrote: >> There is also the size consideration. Unless a seeded ubifs can get >> close to squashfs in terms of compression there would still be a >> use-case for squashfs with an ubifs overlay. My current root as ubifs >> instead of squashfs is 76.8% bigger. > > As seeded files are stored and kept unmodified, they could be stored in > compressed form? This is what UBIFS already does. Thanks, //richard ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS
On Sat, May 20, 2017 at 9:36 PM, Ralph Sennhauser
wrote:
> There is also the size consideration. Unless a seeded ubifs can get
> close to squashfs in terms of compression there would still be a
> use-case for squashfs with an ubifs overlay. My current root as ubifs
> instead of squashfs is 76.8% bigger.
As seeded files are stored and kept unmodified, they could be stored in
compressed form?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] samba: remove browse/write able entries
current LuCI defaults set the former for each individual share. The latter is an inverted synonym for read only, which is configurable through LuCI. Signed-off by: Rosen Penev --- package/network/services/samba36/files/smb.conf.template | 2 -- 1 file changed, 2 deletions(-) diff --git a/package/network/services/samba36/files/smb.conf.template b/package/network/services/samba36/files/smb.conf.template index 47271d9..5f99025 100644 --- a/package/network/services/samba36/files/smb.conf.template +++ b/package/network/services/samba36/files/smb.conf.template @@ -6,7 +6,6 @@ unix charset = |CHARSET| workgroup = |WORKGROUP| local master = no - browseable = yes deadtime = 30 enable core files = no invalid users = root @@ -20,5 +19,4 @@ smb passwd file = /etc/samba/smbpasswd syslog = 2 use sendfile = yes - writeable = yes bind interfaces only = yes -- 2.9.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
