On December 17, 2019 7:28:35 AM UTC, "Rafał Miłecki" wrote:
>From: Pali Rohár
>
>commit e526f503918cc29d8b1ccf36a5c3a34645d2be6e upstream.
>
>When FAT directory entry has leading byte 0x05 it is interpreted as
>byte
>0xE5. This is how FAT stores file name which starts with byte 0xE5 as
>leading
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 ---
ЕРАЛАШ
Детский юмористический
From: Pali Rohár
commit f0ca7e80d7a171701d0d04a3eae22d97f15d0683 upstream.
* Use only label from the root directory and do not fallback to the label
stored in boot sector. This is how MS-DOS 6.22, MS-DOS 7.10, Windows 98,
Windows XP and also Windows 10 behave. Moreover Windows XP and
From: Rafał Miłecki
This stub will allow porting more upstream code without commenting out
calls and them unused variables. This will simplify maintenance.
Signed-off-by: Rafał Miłecki
---
libblkid-tiny/libblkid-tiny.c | 6 ++
libblkid-tiny/superblocks.h | 2 +-
2 files changed, 7
From: Pali Rohár
commit e526f503918cc29d8b1ccf36a5c3a34645d2be6e upstream.
When FAT directory entry has leading byte 0x05 it is interpreted as byte
0xE5. This is how FAT stores file name which starts with byte 0xE5 as
leading byte in 0xE5 in FAT directory entry means that file slot is empty.
From: Rafał Miłecki
This fixes reading vfat labels. With updated code "NO NAME" is no
longer read and so our downstream hack for dropping extra spaces can be
dropped.
Pali Rohár (2):
libblkid: vfat: Fix reading labels which starts with byte 0x05
libblkid: vfat: Change parsing label in
No changes to wave-1, but I make a version .014 copy anyway to keep the
makefile in
sync.
Wave-2 has a fix to make setting txpower work better. Before setting the power
was
ignored at least some of the time (it also appeared to work mostly, so I guess
it
was being correctly set in other
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 ---
ДИСНЕЕВСКИЕ МУЛЬТФИЛЬМЫ
Большая
On 16/12/19 21:04, Christian Lamparter wrote:
Hello,
On Mon, Dec 16, 2019 at 12:27 PM Alberto Bursi
wrote:
On 15/12/19 14:09, Christian Lamparter wrote:
But it seems that Ben had a change of heart in this regard. I don't know the
details or why, But it makes sense because it would
Hallo Matthias,
> Having a WAN port by default is extremely useful (and necessary for easy
> automatic configuration by OpenWrt-based frameworks like Gluon without
> having to special-case many devices).
> I would prefer if we could always make one port WAN as long as we have at
> least two
On 12/16/19 1:31 PM, Adrian Schmutzler wrote:
> The EdgeRouter only has LAN ports labelled eth0 to eth4 (plus
> unsupported eth5 for SFP version). Thus, there is no reason to set
> up one of them as WAN.
>
> This patch sets all ports to "lan" and removes the unused wan_mac.
>
> Actually, stock
Hello,
On Mon, Dec 16, 2019 at 12:27 PM Alberto Bursi
wrote:
>
>
> On 15/12/19 14:09, Christian Lamparter wrote:
> >
> > But it seems that Ben had a change of heart in this regard. I don't know the
> > details or why, But it makes sense because it would enable his company to
> > save
> > some
On 12/16/2019 03:26 AM, Alberto Bursi wrote:
On 15/12/19 14:09, Christian Lamparter wrote:
But it seems that Ben had a change of heart in this regard. I don't know the
details or why, But it makes sense because it would enable his company to save
some money for the systems his company
The EdgeRouter only has LAN ports labelled eth0 to eth4 (plus
unsupported eth5 for SFP version). Thus, there is no reason to set
up one of them as WAN.
This patch sets all ports to "lan" and removes the unused wan_mac.
Actually, stock firmware on the EdgeRouter X assigns a specific MAC
address
This renames lantiq DTS(I) files to follow soc_vendor_device scheme.
This will make DTS files easier to maintain.
As a side effect, DTS file name can be derived from device node
names now, only having to specify a SOC variable in Makefiles.
While at it, move files to arch/mips/boot/dts/lantiq
This splits device definitions into several *.mk files to increase
overview.
Signed-off-by: Adrian Schmutzler
---
target/linux/lantiq/image/Makefile | 857 +--
target/linux/lantiq/image/amazonse.mk| 22 +
target/linux/lantiq/image/ar9.mk | 163 +
This file seems to be orphaned, no device setup existing for it.
Signed-off-by: Adrian Schmutzler
---
.../boot/dts/lantiq/ar9_lantiq_easy50810.dts | 73 ---
1 file changed, 73 deletions(-)
delete mode 100644
This add the device variable SOC and adds it to DEFAULT_DEVICE_VARS.
It is supposed to replace target-specific SOC variables like ATH_SOC
and thus unify variable names.
Signed-off-by: Adrian Schmutzler
---
include/image.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
** Please run-test **
This renames lantiq DTS(I) files to follow soc_vendor_device scheme.
The same patchset is available for easy build at:
https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/lantiq
It is based on the DTS changes proposed in
On 15/12/19 14:09, Christian Lamparter wrote:
But it seems that Ben had a change of heart in this regard. I don't know the
details or why, But it makes sense because it would enable his company to save
some money for the systems his company sells:
20 matches
Mail list logo
