Re: [OpenWrt-Devel] [PATCH fstools 2/3] libblkid: vfat: Fix reading labels which starts with byte 0x05

2019-12-16 Thread Petr Štetiar 
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 byte in 0xE5 in FAT directory entry means that file slot is
>empty.
>
>Fixes: #533

FYI missing SoBs

>---
> libblkid-tiny/vfat.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/libblkid-tiny/vfat.c b/libblkid-tiny/vfat.c
>index 49b865a..93e4053 100644
>--- a/libblkid-tiny/vfat.c
>+++ b/libblkid-tiny/vfat.c
>@@ -167,6 +167,8 @@ static unsigned char *search_fat_label(blkid_probe
>pr,
>   if ((ent->attr & (FAT_ATTR_VOLUME_ID | FAT_ATTR_DIR)) ==
>   FAT_ATTR_VOLUME_ID) {
>   DBG(LOWPROBE, ul_debug("\tfound fs LABEL at entry %d", 
> i));
>+  if (ent->name[0] == 0x05)
>+  ent->name[0] = 0xE5;

Would it be possible to replace this magic values with some #define or such? 

>   return ent->name;
>   }
>   }
>-- 
>2.21.0
>
>
>___
>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

[OpenWrt-Devel] ЕРАЛАШ. Детский юмористический киножурнал - полная коллекция в отличном качестве. 05_08_2019 02_10 199508

2019-12-16 Thread hjskvntjwgvt.ru via openwrt-devel 
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 ---
ЕРАЛАШ
Детский юмористический киножурнал

Здравствуйте, предлагаем Вашему вниманию наиболее полную и качественную 
коллекцию знаменитого детского юмористического киножурнала Ералаш, в которую 
входят все выпуски прошлых лет, а так же современные. Ералаш – это истории 
которые случаются с ребятами в школе и дома, во дворах и на улице. Поучительные 
кинозарисовки прививают молодому поколению любовь и уважение к сверстникам и 
окружающим. Было время, когда на первые звуки "Мальчишки и девчонки..." дети 
бросали все свои дела и бежали к телевизору, что бы посмотреть редкие тогда 
серии. Мы думаем, что детям нужно как можно чаще показывать Ералаш, поскольку 
это интересно, весело и поучительно. Бытует мнение, что современные сюжеты хуже 
старых, но это не так, они не хуже и не лучше старых, поскольку они отражают 
реалии нашего времени. Детского кино сейчас почти нет, поэтому "Ералаш", 
особенно на фоне того, что показывают нашим детям по телевизору, становится 
спасительной соломинкой. Отличительной особенностью нашей коллекции от других, 
является высокое качество. Благодаря современным технологиям удалось сохранить 
оригинальный звук и видео (привычные голоса героев и видео) поэтому коллекция 
отлично смотрится.

Коллекция состоит из 294 выпусков, каждый выпуск состоит из 4-5 серий, общая 
продолжительность ~48 часов. Записана на внешний USB накопитель (флешка). 
Проблем с воспроизведением не возникнет, можно смотреть на компьютере, 
планшете, смартфоне, телевизоре и т.д. Запись на внешний USB накопитель имеет 
ряд преимуществ в сравнении с обычными DVD дисками, USB накопитель гораздо 
легче, занимает меньше места, обладает высокой надёжностью сохранности записей, 
а это значит, что наша коллекция будет радовать Вас много лет. Мы гарантируем 
отличное качество всех записей. На самом носителе создана продуманная 
структура, все записи разнесены по каталогам, имеются плейлисты, прописаны 
теги, а также полный список вошедших записей, поэтому проблем с поиском и 
навигацией не возникнет.

Стоимость коллекции на внешнем USB накопителе — 6500 (Шесть Тысяч Пятьсот) 
Рублей.
Продаются только вместе. Доставка включена в стоимость.

Доставка и оплата коллекции осуществляется только по России — почтой, 
наложенным платежом, никакой предоплаты не требуется, оплата только в момент 
получения на почте, доставка включена в стоимость. Сроки доставки зависят от 
расстояния и степени загрузки почты, но как правило это 7-14 суток с момента 
отправки. Напоминаем, что у нас нет курьерской доставки — только почтой, в том 
числе и по Москве.

Для оформления заказа просьба не забывать указывать:
 --- Ваш почтовый индекс (пишите правильный индекс — это ускорит доставку);
 --- Ваш город и точный адрес (название улицы, номер дома и номер квартиры);
 --- Ф.И.О. получателя и ОБЯЗАТЕЛЬНО номер контактного телефона (лучше сотовый);
Заказы\вопросы направляйте по адресу: eralashfi...@cwhflash.ru

По вашему желанию, данная коллекция может быть записана на DVD диски. Для 
записи используются надёжные DVD диски со специальным покрытием, которое 
повышает устойчивость диска к механическим повреждениям, таким как трещины и 
царапины, а это значит, что наша коллекция будет радовать Вас много лет. 
Коллекция упакована в пластиковые боксы (slim-dvd), имеет красивые и 
продуманные обложки, с обратной стороны которых указан список вошедших на 
каждый диск выпусков и другая полезная информация, поэтому проблем с поиском и 
навигацией не возникнет. Если хотите приобрести коллекцию, записанную на DVD 
дисках, то в этом случае просьба сообщить нам об этом в своей заявке, цена 
прежняя, как у версии на внешнем USB накопителе (флешка) — 6500 (Шесть Тысяч 
Пятьсот) Рублей.

Если вы не хотите больше получать от нас письма, отправьте нам письмо с темой 
“deletemail” и Ваш адрес навсегда будет удален автоматически.

05_08_2019 02_10 199508

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

[OpenWrt-Devel] [PATCH fstools 3/3] libblkid: vfat: Change parsing label in special cases

2019-12-16 Thread Rafał Miłecki 
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 Windows 10
  do not touch label in boot sector anymore, so removing FAT label on those
  Windowses leads to having old label still stored in boot sector (which
  MS-DOS and Windows fully ignore).

* Label entry "NO NAME" in root directory is treated as label "NO NAME"
  instead of empty label. In root directory it has no special meaning.
  String "NO NAME" has a special meaning (empty label) only for label
  stored in boot sector.

* Label from the boot sector is now stored into LABEL_FATBOOT field. So if
  there are applications which depends or needs to read this label, they
  have ability.

After this change LABEL always correspondent to the label from the root
directory and LABEL_FATBOOT to the label stored in the boot sector. If some
of those labels is missing or is not present (e.g. "NO LABEL" in boot
sector) then particular field is not set.

Signed-off-by: Pali Rohár 
[rmilecki: drop unneeded now downstream hacks for handling spaces]
Signed-off-by: Rafał Miłecki 
---
 libblkid-tiny/vfat.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/libblkid-tiny/vfat.c b/libblkid-tiny/vfat.c
index 93e4053..e70dd75 100644
--- a/libblkid-tiny/vfat.c
+++ b/libblkid-tiny/vfat.c
@@ -305,11 +305,11 @@ static int probe_vfat(blkid_probe pr, const struct 
blkid_idmag *mag)
struct vfat_super_block *vs;
struct msdos_super_block *ms;
unsigned char *vol_label = 0;
+   const unsigned char *boot_label = NULL;
unsigned char *vol_serno = NULL, vol_label_buf[12] = { 0 };
uint16_t sector_size = 0, reserved;
uint32_t cluster_count, fat_size;
const char *version = NULL;
-   int i;
 
ms = blkid_probe_get_sb(pr, mag, struct msdos_super_block);
if (!ms)
@@ -336,8 +336,7 @@ static int probe_vfat(blkid_probe pr, const struct 
blkid_idmag *mag)
vol_label = vol_label_buf;
}
 
-   if (!vol_label || !memcmp(vol_label, no_name, 11))
-   vol_label = ms->ms_label;
+   boot_label = ms->ms_label;
vol_serno = ms->ms_serno;
 
blkid_probe_set_value(pr, "SEC_TYPE", (unsigned char *) "msdos",
@@ -391,8 +390,7 @@ static int probe_vfat(blkid_probe pr, const struct 
blkid_idmag *mag)
 
version = "FAT32";
 
-   if (!vol_label || !memcmp(vol_label, no_name, 11))
-   vol_label = vs->vs_label;
+   boot_label = vs->vs_label;
vol_serno = vs->vs_serno;
 
/*
@@ -421,13 +419,10 @@ static int probe_vfat(blkid_probe pr, const struct 
blkid_idmag *mag)
}
}
 
-   for (i = 10; i >= 0; i--) {
-   if (vol_label[i] != ' ')
-   break;
-   vol_label[i] = '\0';
-   }
+   if (boot_label && memcmp(boot_label, no_name, 11))
+   blkid_probe_set_id_label(pr, "LABEL_FATBOOT", (unsigned char *) 
boot_label, 11);
 
-   if (vol_label && memcmp(vol_label, no_name, 11))
+   if (vol_label)
blkid_probe_set_label(pr, (unsigned char *) vol_label, 11);
 
/* We can't just print them as %04X, because they are unaligned */
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH fstools 1/3] libblkid-tiny: add blkid_probe_set_id_label() stub

2019-12-16 Thread Rafał Miłecki 
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 insertions(+), 1 deletion(-)

diff --git a/libblkid-tiny/libblkid-tiny.c b/libblkid-tiny/libblkid-tiny.c
index 05b4b99..52470ca 100644
--- a/libblkid-tiny/libblkid-tiny.c
+++ b/libblkid-tiny/libblkid-tiny.c
@@ -101,6 +101,12 @@ unsigned char *blkid_probe_get_buffer(blkid_probe pr,
return bf->data;
 }
 
+int blkid_probe_set_id_label(blkid_probe pr, const char *name,
+const unsigned char *data, size_t len)
+{
+   return -ENOTSUP;
+}
+
 int blkid_probe_set_label(blkid_probe pr, unsigned char *label, size_t len)
 {
if (len > (sizeof(pr->label) - 1)) {
diff --git a/libblkid-tiny/superblocks.h b/libblkid-tiny/superblocks.h
index cde8a40..ade2ae0 100644
--- a/libblkid-tiny/superblocks.h
+++ b/libblkid-tiny/superblocks.h
@@ -97,7 +97,7 @@ extern int blkid_probe_set_uuid(blkid_probe pr, unsigned char 
*uuid);
 extern int blkid_probe_set_uuid_as(blkid_probe pr, unsigned char *uuid, const 
char *name);
 
 extern int blkid_probe_set_id_label(blkid_probe pr, const char *name,
-unsigned char *data, size_t len);
+const unsigned char *data, size_t len);
 extern int blkid_probe_set_utf8_id_label(blkid_probe pr, const char *name,
 unsigned char *data, size_t len, int enc);
 
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH fstools 2/3] libblkid: vfat: Fix reading labels which starts with byte 0x05

2019-12-16 Thread Rafał Miłecki 
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.

Fixes: #533
---
 libblkid-tiny/vfat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libblkid-tiny/vfat.c b/libblkid-tiny/vfat.c
index 49b865a..93e4053 100644
--- a/libblkid-tiny/vfat.c
+++ b/libblkid-tiny/vfat.c
@@ -167,6 +167,8 @@ static unsigned char *search_fat_label(blkid_probe pr,
if ((ent->attr & (FAT_ATTR_VOLUME_ID | FAT_ATTR_DIR)) ==
FAT_ATTR_VOLUME_ID) {
DBG(LOWPROBE, ul_debug("\tfound fs LABEL at entry %d", 
i));
+   if (ent->name[0] == 0x05)
+   ent->name[0] = 0xE5;
return ent->name;
}
}
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH fstools 0/3] libblkid-tiny: cherry-pick upstream vfat fixes

2019-12-16 Thread Rafał Miłecki 
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 special cases

Rafał Miłecki (1):
  libblkid-tiny: add blkid_probe_set_id_label() stub

 libblkid-tiny/libblkid-tiny.c |  6 ++
 libblkid-tiny/superblocks.h   |  2 +-
 libblkid-tiny/vfat.c  | 19 ---
 3 files changed, 15 insertions(+), 12 deletions(-)

-- 
2.21.0


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

[OpenWrt-Devel] New ath10k-ct wave-2 firmware available

2019-12-16 Thread Ben Greear 

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 ways).

988x
19db86003509dedb8ace339c183813ca637d65af24d00666411d1590efe33e13  
firmware-2-ct-full-community-22.bin.lede.014
454e67dab545e720369a07be2fee16de008c76db4ab3119e7760bf9f7504c066  
firmware-2-ct-full-htt-mgt-community-22.bin.lede.014
/home/greearb/candela_html/downloads
9887
b3c738328427e124701a5735d65cde0f60e4172ae5bc23b00e5b16df7995dbd4  
firmware-2-ct-full-community-22.bin.lede.014
4432ccee23133bbaa4a5552e50a1e7e889b257362603e05530e751b67c29b7b5  
firmware-2-ct-full-htt-mgt-community-22.bin.lede.014
/home/greearb/candela_html/downloads
9980
9a908f743604a468b651a5f73c49e6b0ba11a05c677b9726fbf041b849d88b25  
firmware-5-ct-full-community-12.bin-lede.014
800dd0816702aaca75f3eb5436c2ea724a6c24833838cd54399b9286b4d4fbe8  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.014
/home/greearb/candela_html/downloads
9984
a8b12dba478e8c9d4a215f82324382c7554a900e83c31775f8511af84e59fef7  
firmware-5-ct-full-community-12.bin-lede.014
d185651b5d3d1f0082720bc6c2bbe43b2a00cdb6333403fac9336a720b1d93ae  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.014
/home/greearb/candela_html/downloads
4019
4c2e48835219f420b18dc58e31d1387dae0da70d8170c3fc5e7bce39c06cf355  
firmware-5-ct-full-community-12.bin-lede.014
743da4d537d094a7839bd8e1f792e4cb8b517101f66777c84fd84585f0b85e64  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.014
/home/greearb/candela_html/downloads
9888
5809c8a6b3bd81cbc829b5e90af3c0a3300488fe194524a90e260448158016b6  
firmware-5-ct-full-community-12.bin-lede.014
a284943c203ff66ec2e865f20ae2d2aa049b450801d7205b53c9163862228f15  
firmware-5-ct-full-htt-mgt-community-12.bin-lede.014
/home/greearb/candela_html/downloads


Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

[OpenWrt-Devel] Диснеевские мультфильмы - большая коллекция в отличном качестве. 05_08_2019 02_10 199508

2019-12-16 Thread hjskvntjwgvt.ru via openwrt-devel 
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 ---
ДИСНЕЕВСКИЕ МУЛЬТФИЛЬМЫ
Большая коллекция, состоящая из 83 мультфильмов!

Предлагаем Вашему вниманию коллекцию полнометражных диснеевских мультфильмов, 
все вошедшие в коллекцию мультики сделаны как фильмы – это очень красивые и 
интересные мультфильмы, которые всегда учат добру и имеют мораль. Это то, что 
всегда было и будет интересным и взрослым и детям, особенно учитывая те ужасы, 
которые в последнее время крутят по телевизору. Поэтому мы считаем, что дети 
должны расти именно на таких мультфильмах, да и многим взрослым тоже полезно 
хоть изредка такое смотреть, возможно, наша жизнь изменилась бы к лучшему. 
Вошедшие в коллекцию мультфильмы без преувеличения можно назвать настоящими 
шедеврами, поскольку они такие добрые и трогательные, красивые и музыкальные, а 
главное в них добро всегда побеждает зло. Большинство детей и взрослых после 
просмотра остаются в полном восторге!

Список мультфильмов: 101 далматинец; Алиса в стране чудес; Алладин - 1 часть; 
Алладин - 2 часть; Анастасия; Артур и минипуты; Атлантида Затерянный мир; 
Белоснежка и семь гномов; Би Муви - Медовый заговор; Большое путешествие; 
Братец медвежонок - 1 часть; Братец медвежонок - 2 часть; Бэмби; В гости к 
Робинсонам; В поисках немо; Вверх; Великий Мышиный Сыщик; Волшебное Рождество у 
Микки; Вольт; Все псы попадают в рай - 1 часть; Все псы попадают в рай - 2 
часть; Гадкий Я; Геркулес; Горбун из Нотр Дама - 1 часть; Горбун из Нотр Дама - 
2 часть; Дамбо; Дюймовочка; Золушка - 1 часть; Золушка - 2 часть; История 
игрушек - 1 часть; История игрушек - 2 часть; История игрушек - 3 часть; Как 
приручить дракона; Каникулы Гуфи; Книга джунглей - 1 часть; Книга джунглей - 2 
часть; Король Лев - 1 часть; Король Лев - 2 часть; Король Лев - 3 часть; Коты - 
Аристократы; Красавица и чудовище; Кунг Фу Панда; Легенда сонной лощины; Леди и 
бродяга; Ледниковый период - 1 часть; Ледниковый период - 2 часть; Ледниковый 
период - 3 часть; Лило и Стич; Лис и охотничий пёс; Мадагаскар - 1 часть; 
Мадагаскар - 2 часть; Мегамозг; Меч в камне; Мулан; Не бей копытом; Оливер и 
компания; Пиноккио; Питер Пен; Планета сокровищ; Покахонтас - 1 часть; 
Покахонтас - 2 часть; Похождение императора; Привет друзья; Приключения Винни 
Пуха; Приключения Икабода и Тоада; Рапунцель; Рататуй; Робин Гуд; Русалочка; 
Спасатели; Спасатели в Австралии; Спящаяя красавица; Суперсемейка; Тарзан - 1 
часть; Тарзан - 2 часть; Три кабальеро; Фантазия - 1 часть; Фантазия - 2 часть; 
Цыплёнок Цыпа; Чёрный котёл; Шрек - 1 часть; Шрек - 2 часть; Шрек - 3 часть;

Коллекция состоит из 83 мультфильмов. Записана на внешний USB накопитель 
(флешка). Проблем с воспроизведением не возникнет, можно смотреть на 
компьютере, планшете, смартфоне, телевизоре и т.д. Запись на внешний USB 
накопитель имеет ряд преимуществ в сравнении с обычными DVD дисками, USB 
накопитель гораздо легче, занимает меньше места, обладает высокой надёжностью 
сохранности записей, а это значит, что наша коллекция будет радовать Вас много 
лет. Мы гарантируем отличное качество всех записей. На самом носителе создана 
продуманная структура, все записи разнесены по каталогам, имеются плейлисты, 
прописаны теги, а также полный список вошедших записей, поэтому проблем с 
поиском и навигацией не возникнет.

Стоимость коллекции на внешнем USB накопителе — 6500 (Шесть Тысяч Пятьсот) 
Рублей.
Продаются только вместе. Доставка включена в стоимость.

Доставка и оплата коллекции осуществляется только по России — почтой, 
наложенным платежом, никакой предоплаты не требуется, оплата только в момент 
получения на почте, доставка включена в стоимость. Сроки доставки зависят от 
расстояния и степени загрузки почты, но как правило это 7-14 суток с момента 
отправки. Напоминаем, что у нас нет курьерской доставки — только почтой, в том 
числе и по Москве.

Для оформления заказа просьба не забывать указывать:
 --- Ваш почтовый индекс (пишите правильный индекс — это ускорит доставку);
 --- Ваш город и точный адрес (название улицы, номер дома и номер квартиры);
 --- Ф.И.О. получателя и ОБЯЗАТЕЛЬНО номер контактного телефона (лучше сотовый);
Заказы\вопросы направляйте по адресу: disneymultfi...@cwhflash.ru

Мы очень ответственно относимся к качеству нашего товара, поэтому перед 
отправкой всё дополнительно проверяется, как следствие отправка бракованной 
продукции сведена к нулю. Товар упаковывается в специальный ударостойкий 
материал, что в значительной степени уменьшает риск повреждения при 
транспортировке. Если вдруг с полученным товаром возникнут проблемы, то все 
наши покупатели всегда могут рассчитывать на квалифицированную техническую 
поддержку. Мы никогда не отказываемся от гарантийных обязательств, в случае 
проблемы Вы можете рассчитывать на замену, почтовые

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-16 Thread Alberto Bursi 




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 enable his company to save
some money for the systems his company sells:
    so there is some value
in supporting these devices, especially if someone else does all the work
for it.


These are wifi/network testing equipment, not network devices.

Also I don't see the value in "saving some money" by using a bit less RAM

when the cheaper system is sold for 3k, and most stuff is above 10k.

You could use standard whitebox x86 stuff at that price point.


I'm glad this is getting some attention and others are chiming in. But
let me tell
you first, that I'm not an opponent of the "American way", I'm trying
to make sense
of it though and also what would happen to the ath10k GPIO patches that got
quietly dropped from your reply there...
I was just commenting about the fact that they clearly don't care about 
RAM consumption for their own hardware, I found it strange that you 
pulled that up as a "potential way to save money".


Saving 10-20$ (RAM prices) on a low-volume high-price item costing 
thousands of dollars is mostly irrelevant.




As for the "These are wifi/network testing equipment, not network devices."
True and If you are interested you can buy cheaper devices like
 from the company as well:



When I said "expensive devices" I was talking of their devices that 
could mount a ath10k-supported card. A Raspi really does not.




I know these have not much to do with the issue at hand ("low-memory system"
support in ath10k(-ct) with OpenWrt). But as Ben explained in the follow-up that
he has a keen interest for supporting the ath10k-ct driver+firmware
and he's doing
a great job with the ath10k-ct issue tracker.



I fully agree with merging and possibly upstreaming the current patches 
about a build option to reduce buffer sizes so that this thing does not 
OOM on devices that OpenWrt supports.


My remarks about RAM usage being irrelevant was specifc to their own 
usecase in their "expensive test equipment".


-Alberto

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

Re: [OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti EdgeRouter X (and SFP)

2019-12-16 Thread mail 
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 independently configurable ports, regardless of labeling - at 
> least that was my policy for creating new hardware support in the past. 
> Regards, 
> Matthias 

while I understand your reasoning, I look at this from a different angle:
On a device with five equivalent ports, I would expect those to be still 
equivalent in OpenWrt. Having an arbitrary port chosen to be a WAN port is 
rather confusing in that situation; users may only realize that if they really 
look into the configuration in the first place. Consequently, I would handle 
this the opposite way: For the uneducated user downloading the prebuild image, 
I would provide the setup which is supposed to be "expected". Experienced users 
and downstream developers (as I am myself) would then be able to change 
configuration to their particular demands. Though one could argue that the 
uneducated user would also be troubled to set up a WAN port if he wanted it, 
this is already assuming a certain use case which I would not do for the 
default settings (where I would plead that the user expects what the device is 
built for).
To make it even worse, having the predefined wan port for this device in 
particular will mess up the port order in luci, where ports are ordered "1 2 3 
4 0" because 0 is wan. On the device, ports are 0 1 2 3 4 ...

Note that this is not just my personal opinion: I actually was made aware of 
the situation with the EdgeRouter by a user who reported the situation, 
complaining about having to configure away the WAN port for this device and 
being annoyed by the luci issue.

So, I'd still prefer to have this device switched to lan-only.

Best

Adrian


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

Re: [OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti EdgeRouter X (and SFP)

2019-12-16 Thread Matthias Schiffer 
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 firmware on the EdgeRouter X assigns a specific MAC
> address to each port:
> 
> eth0*:f4 (label)
> eth1*:f5
> eth2*:f6
> eth3*:f7
> eth4*:f8
> switch0 *:f9
> 
> (No data for SFP version)
> 
> Only the label MAC is stored on flash in factory 0x22.
> 
> OpenWrt currently sets  to this address, so all ports will
> use that one in OpenWrt.
> 
> Signed-off-by: Adrian Schmutzler 

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 independently configurable ports, regardless of labeling - at
least that was my policy for creating new hardware support in the past.

Regards,
Matthias


> ---
>  .../ramips/mt7621/base-files/etc/board.d/02_network   | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network 
> b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> index 5c6b5659cb..6dfe24e296 100755
> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> @@ -62,8 +62,6 @@ ramips_setup_interfaces()
>   asus,rt-ac85p|\
>   iptime,a6ns-m|\
>   mikrotik,rb750gr3|\
> - ubiquiti,edgerouterx|\
> - ubiquiti,edgerouterx-sfp|\
>   youhua,wr1200js)
>   ucidef_add_switch "switch0" \
>   "1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
> @@ -124,6 +122,11 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "0:lan" "6@eth0"
>   ;;
> + ubiquiti,edgerouterx|\
> + ubiquiti,edgerouterx-sfp)
> + ucidef_add_switch "switch0" \
> + "0:lan" "1:lan" "2:lan" "3:lan" "4:lan" "6@eth0"
> + ;;
>   xiaomi,mir3g)
>   ucidef_add_switch "switch0" \
>   "2:lan:2" "3:lan:1" "1:wan" "6t@eth0"
> @@ -246,10 +249,6 @@ ramips_setup_macs()
>   telco-electronics,x1)
>   wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 0xe006)" 1)
>   ;;
> - ubiquiti,edgerouterx|\
> - ubiquiti,edgerouterx-sfp)
> - wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 0x22)" 1)
> - ;;
>   wevo,11acnas|\
>   wevo,w2914ns-v2|\
>   zio,freezio)
> 




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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-16 Thread Christian Lamparter 
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 money for the systems his company sells:
> >    so there is some value
> > in supporting these devices, especially if someone else does all the work
> > for it.
>
> These are wifi/network testing equipment, not network devices.
>
> Also I don't see the value in "saving some money" by using a bit less RAM
>
> when the cheaper system is sold for 3k, and most stuff is above 10k.
>
> You could use standard whitebox x86 stuff at that price point.

I'm glad this is getting some attention and others are chiming in. But
let me tell
you first, that I'm not an opponent of the "American way", I'm trying
to make sense
of it though and also what would happen to the ath10k GPIO patches that got
quietly dropped from your reply there...

As for the "These are wifi/network testing equipment, not network devices."
True and If you are interested you can buy cheaper devices like
 from the company as well:

"The CT314 is a low-power and affordable applicance with a single 10/100
Ethernet port and one Broadcome 802.11b/g/n Wireless interface. It is targeted
at users who wish to have an inexpensive appliance that can be left at remote
sites for network monitoring and lower speed testing. The maximum throughput
is about 90Mbps bi-directional wired. Wireless throughput is steady at 38Mbps
and can peak at 48Mpbs. The CT314 is based on the Raspberry PI B version 3
platform, running the Ubuntu Server OS. [...]".

I know these have not much to do with the issue at hand ("low-memory system"
support in ath10k(-ct) with OpenWrt). But as Ben explained in the follow-up that
he has a keen interest for supporting the ath10k-ct driver+firmware
and he's doing
a great job with the ath10k-ct issue tracker.

Cheers,
Christian

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

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-16 Thread Ben Greear 




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 sells:
   so there is some value
in supporting these devices, especially if someone else does all the work
for it.


These are wifi/network testing equipment, not network devices.

Also I don't see the value in "saving some money" by using a bit less RAM

when the cheaper system is sold for 3k, and most stuff is above 10k.

You could use standard whitebox x86 stuff at that price point.


The low-ram thing is for people using OpenWRT on low-powered AP boards.  We 
don't
need it for our test equipment.

Hopefully someone can test Paul Fertser's patches, and if they work well, then 
can
be applied to OpenWRT.

Maybe later we can conditionally compile it directly into ath10k-ct instead of 
having
the extra patch in OpenWRT.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

[OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti EdgeRouter X (and SFP)

2019-12-16 Thread Adrian Schmutzler 
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 to each port:

eth0*:f4 (label)
eth1*:f5
eth2*:f6
eth3*:f7
eth4*:f8
switch0 *:f9

(No data for SFP version)

Only the label MAC is stored on flash in factory 0x22.

OpenWrt currently sets  to this address, so all ports will
use that one in OpenWrt.

Signed-off-by: Adrian Schmutzler 
---
 .../ramips/mt7621/base-files/etc/board.d/02_network   | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network 
b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
index 5c6b5659cb..6dfe24e296 100755
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
@@ -62,8 +62,6 @@ ramips_setup_interfaces()
asus,rt-ac85p|\
iptime,a6ns-m|\
mikrotik,rb750gr3|\
-   ubiquiti,edgerouterx|\
-   ubiquiti,edgerouterx-sfp|\
youhua,wr1200js)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
@@ -124,6 +122,11 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "6@eth0"
;;
+   ubiquiti,edgerouterx|\
+   ubiquiti,edgerouterx-sfp)
+   ucidef_add_switch "switch0" \
+   "0:lan" "1:lan" "2:lan" "3:lan" "4:lan" "6@eth0"
+   ;;
xiaomi,mir3g)
ucidef_add_switch "switch0" \
"2:lan:2" "3:lan:1" "1:wan" "6t@eth0"
@@ -246,10 +249,6 @@ ramips_setup_macs()
telco-electronics,x1)
wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 0xe006)" 1)
;;
-   ubiquiti,edgerouterx|\
-   ubiquiti,edgerouterx-sfp)
-   wan_mac=$(macaddr_add "$(mtd_get_mac_binary factory 0x22)" 1)
-   ;;
wevo,11acnas|\
wevo,w2914ns-v2|\
zio,freezio)
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 3/4] lantiq: use soc_vendor_device scheme on DTS file

2019-12-16 Thread Adrian Schmutzler 
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 subfolder.

Signed-off-by: Adrian Schmutzler 
---
 .../mips/boot/dts/{ => lantiq}/amazonse.dtsi  |  0
 .../amazonse_allnet_all0333cj.dts}|  0
 .../amazonse_netgear_dgn1000b.dts}|  0
 .../arch/mips/boot/dts/{ => lantiq}/ar9.dtsi  |  0
 .../ar9_avm_fritz7312.dts}|  0
 .../ar9_avm_fritz7320.dts}|  0
 .../ar9_bt_homehub-v3a.dts}   |  0
 .../ar9_buffalo_wbmr-hp-g300h.dts}|  0
 .../ar9_lantiq_easy50810.dts} |  0
 .../ar9_netgear_dgn3500.dts}  |  2 +-
 .../ar9_netgear_dgn3500.dtsi} |  0
 .../ar9_netgear_dgn3500b.dts} |  2 +-
 .../{H201L.dts => lantiq/ar9_zte_h201l.dts}   |  0
 .../ar9_zyxel_p-2601hn.dts}   |  0
 .../mips/boot/dts/{ => lantiq}/danube.dtsi|  0
 .../danube_arcadyan_arv4510pw.dts}|  0
 .../danube_arcadyan_arv4518pwr01.dts} |  2 +-
 .../danube_arcadyan_arv4518pwr01.dtsi}|  0
 .../danube_arcadyan_arv4518pwr01a.dts}|  2 +-
 .../danube_arcadyan_arv4519pw.dts}|  0
 .../danube_arcadyan_arv4520pw.dts}|  0
 .../danube_arcadyan_arv4525pw.dts}|  0
 .../danube_arcadyan_arv452cqw.dts}|  0
 .../danube_arcadyan_arv7506pw11.dts}  |  0
 .../danube_arcadyan_arv7510pw22.dts}  |  0
 .../danube_arcadyan_arv7518pw.dts}|  0
 .../danube_arcadyan_arv7519pw.dts}|  0
 .../danube_arcadyan_arv7525pw.dts}|  0
 .../danube_arcadyan_arv752dpw.dts}|  0
 .../danube_arcadyan_arv752dpw22.dts}  |  0
 .../danube_arcadyan_arv8539pw22.dts}  |  0
 .../danube_audiocodes_mp-252.dts} |  0
 .../danube_bt_homehub-v2b.dts}|  0
 .../danube_lantiq_easy50712.dts}  |  0
 .../danube_siemens_gigaset-sx76x.dts} |  0
 .../mips/boot/dts/{ => lantiq}/falcon.dtsi|  0
 .../falcon_lantiq_easy88388.dts}  |  2 +-
 .../falcon_lantiq_easy88444.dts}  |  2 +-
 .../falcon_lantiq_easy98000-nand.dts} |  2 +-
 .../falcon_lantiq_easy98000-nor.dts}  |  2 +-
 .../falcon_lantiq_easy98000-sflash.dts}   |  4 +-
 .../falcon_lantiq_easy98000.dtsi} |  0
 .../falcon_lantiq_easy98020-v18.dts}  |  2 +-
 .../falcon_lantiq_easy98020.dts}  |  2 +-
 .../falcon_lantiq_easy98021.dts}  |  2 +-
 .../falcon_lantiq_easy98035synce.dts} |  2 +-
 .../falcon_lantiq_easy98035synce1588.dts} |  2 +-
 .../falcon_lantiq_falcon-mdu.dts} |  2 +-
 .../falcon_lantiq_falcon-sfp.dts} |  2 +-
 .../falcon_sflash-16m.dtsi}   |  0
 .../arch/mips/boot/dts/{ => lantiq}/vr9.dtsi  |  0
 .../vr9_alphanetworks_asl56026.dts}   |  0
 .../vr9_arcadyan_arv7519rw22.dts} |  0
 .../vr9_arcadyan_vg3503j.dts} |  0
 .../vr9_arcadyan_vgv7510kw22-brn.dts} |  2 +-
 .../vr9_arcadyan_vgv7510kw22-nor.dts} |  2 +-
 .../vr9_arcadyan_vgv7510kw22.dtsi}|  0
 .../vr9_arcadyan_vgv7519-brn.dts} |  2 +-
 .../vr9_arcadyan_vgv7519-nor.dts} |  2 +-
 .../vr9_arcadyan_vgv7519.dtsi}|  0
 .../vr9_avm_fritz3370-rev2-hynix.dts} |  2 +-
 .../vr9_avm_fritz3370-rev2-micron.dts}|  2 +-
 .../vr9_avm_fritz3370-rev2.dtsi}  |  0
 .../vr9_avm_fritz7360sl.dts}  |  2 +-
 .../vr9_avm_fritz7362sl.dts}  |  2 +-
 .../vr9_avm_fritz736x.dtsi}   |  0
 .../vr9_avm_fritz7412.dts}|  0
 .../vr9_bt_homehub-v5a.dts}   |  0
 .../vr9_buffalo_wbmr-300hpd.dts}  |  0
 .../vr9_lantiq_easy80920-nand.dts}|  2 +-
 .../vr9_lantiq_easy80920-nor.dts} |  2 +-
 .../vr9_lantiq_easy80920.dtsi}|  0
 .../vr9_netgear_dm200.dts}|  0
 .../vr9_tplink_tdw8970.dts}   |  2 +-
 .../vr9_tplink_tdw8980.dts}   |  2 +-
 .../vr9_tplink_tdw89x0.dtsi}  |  0
 .../vr9_tplink_vr200.dts} |  2 +-
 .../vr9_tplink_vr200.dtsi}|  0
 .../vr9_tplink_vr200v.dts}|  2 +-
 .../vr9_zyxel_p-2812hnu-f1.dts}   |  2 +-
 .../vr9_zyxel_p-2812hnu-f3.dts}   |  2 +-
 .../vr9_zyxel_p-2812hnu-fx.dtsi}  |  0
 target/linux/lantiq/image/Makefile|  2 +
 target/linux/lantiq/image/amazonse.mk |  4 +-
 target/linux/lantiq/image/ar9.mk  | 20 +-
 target/linux/lantiq/image/danube.mk   | 28 +++---
 target/linux/lantiq/image/falcon.mk   | 24

[OpenWrt-Devel] [PATCH 1/4] lantiq: split device definitions into files

2019-12-16 Thread Adrian Schmutzler 
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 +
 target/linux/lantiq/image/danube.mk  | 219 ++
 target/linux/lantiq/image/falcon.mk  | 105 +++
 target/linux/lantiq/image/vr9.mk | 246 +++
 target/linux/lantiq/image/xway_legacy.mk |  77 ++
 7 files changed, 838 insertions(+), 851 deletions(-)
 create mode 100644 target/linux/lantiq/image/amazonse.mk
 create mode 100644 target/linux/lantiq/image/ar9.mk
 create mode 100644 target/linux/lantiq/image/danube.mk
 create mode 100644 target/linux/lantiq/image/falcon.mk
 create mode 100644 target/linux/lantiq/image/vr9.mk
 create mode 100644 target/linux/lantiq/image/xway_legacy.mk

diff --git a/target/linux/lantiq/image/Makefile 
b/target/linux/lantiq/image/Makefile
index bfb5390465..a2052ef924 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -108,872 +108,27 @@ define Device/AVM
 endef
 
 ifeq ($(SUBTARGET),ase)
-
-define Device/allnet_all0333cj
-  DEVICE_VENDOR := Allnet
-  DEVICE_MODEL := ALL0333CJ
-  IMAGE_SIZE := 3700k
-  DEVICE_DTS := ALL0333CJ
-  DEVICE_PACKAGES := kmod-ltq-adsl-ase kmod-ltq-adsl-ase-mei \
-   kmod-ltq-adsl-ase-fw-b kmod-ltq-atm-ase \
-   ltq-adsl-app ppp-mod-pppoe
-endef
-TARGET_DEVICES += allnet_all0333cj
-
-define Device/netgear_dgn1000b
-  DEVICE_VENDOR := NETGEAR
-  DEVICE_MODEL := DGN1000B
-  IMAGE_SIZE := 6000k
-  DEVICE_DTS := DGN1000B
-  DEVICE_PACKAGES := kmod-ltq-adsl-ase kmod-ltq-adsl-ase-mei \
-   kmod-ltq-adsl-ase-fw-b kmod-ltq-atm-ase \
-   ltq-adsl-app ppp-mod-pppoe
-  SUPPORTED_DEVICES += DGN1000B
-endef
-TARGET_DEVICES += netgear_dgn1000b
-
+include amazonse.mk
 endif
 
 ifeq ($(SUBTARGET),xway_legacy)
-
-define Device/arcadyan_arv4518pwr01
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV4518PWR01
-  IMAGE_SIZE := 3776k
-  DEVICE_DTS := ARV4518PWR01
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-   kmod-ltq-adsl-danube-fw-a kmod-ltq-atm-danube \
-   ltq-adsl-app ppp-mod-pppoa \
-   kmod-ath5k wpad-mini
-  SUPPORTED_DEVICES += ARV4518PWR01
-endef
-TARGET_DEVICES += arcadyan_arv4518pwr01
-
-define Device/arcadyan_arv4518pwr01a
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV4518PWR01A
-  IMAGE_SIZE := 3776k
-  DEVICE_DTS := ARV4518PWR01A
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-   kmod-ltq-adsl-danube-fw-a kmod-ltq-atm-danube \
-   ltq-adsl-app ppp-mod-pppoa \
-   kmod-ath5k wpad-basic
-  SUPPORTED_DEVICES += ARV4518PWR01A
-endef
-TARGET_DEVICES += arcadyan_arv4518pwr01a
-
-define Device/arcadyan_arv4520pw
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV4520PW
-  DEVICE_ALT0_VENDOR := Vodafone
-  DEVICE_ALT0_MODEL := Easybox 800
-  DEVICE_ALT1_VENDOR := Airties
-  DEVICE_ALT1_MODEL := WAV-281
-  IMAGE_SIZE := 3648k
-  DEVICE_DTS := ARV4520PW
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-   kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \
-   ltq-adsl-app ppp-mod-pppoa \
-   kmod-rt61-pci wpad-mini
-  SUPPORTED_DEVICES += ARV4520PW
-endef
-TARGET_DEVICES += arcadyan_arv4520pw
-
-define Device/arcadyan_arv4525pw
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV4525PW
-  DEVICE_ALT0_VENDOR := Telekom
-  DEVICE_ALT0_MODEL := Speedport W502V
-  DEVICE_ALT0_VARIANT := Typ A
-  IMAGE_SIZE := 3776k
-  DEVICE_DTS := ARV4525PW
-  DEVICE_PACKAGES := kmod-ath5k wpad-mini \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-   kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \
-   ltq-adsl-app ppp-mod-pppoa -swconfig
-  SUPPORTED_DEVICES += ARV4525PW
-endef
-TARGET_DEVICES += arcadyan_arv4525pw
-
-define Device/arcadyan_arv452cqw
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV452CQW
-  DEVICE_ALT0_VENDOR := Vodafone
-  DEVICE_ALT0_MODEL := Easybox 801
-  IMAGE_SIZE := 3776k
-  DEVICE_DTS := ARV452CQW
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport \
-   kmod-ath5k wpad-mini \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-   kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \
-   ltq-adsl-app ppp-mod-pppoa
-  SUPPORTED_DEVICES += ARV452CQW
-endef
-TARGET_DEVICES += arcadyan_arv452cqw
-
+include xway_legacy.mk
 endif
 
 ifeq ($(SUBTARGET),xway)
-
-# Danube
-
-define Device/arcadyan_arv4510pw
-  DEVICE_VENDOR := Arcadyan
-  DEVICE_MODEL := ARV4510PW
-  DEVICE_ALT0_VENDOR := Wippies
-  DEVICE_ALT0_MODEL := BeWan iBox v1.0
-  IMAGE_SIZE := 15616k
-  DEVICE_DTS := ARV4510PW
-  DEVICE_PACKAGES := kmod-usb-ledtrig-usbport kmod-usb2-pci kmod-usb-uhci \
-   kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
-

[OpenWrt-Devel] [PATCH 4/4] lantiq: remove ar9_lantiq_easy50810.dts

2019-12-16 Thread Adrian Schmutzler 
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 
target/linux/lantiq/files/arch/mips/boot/dts/lantiq/ar9_lantiq_easy50810.dts

diff --git 
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/ar9_lantiq_easy50810.dts 
b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/ar9_lantiq_easy50810.dts
deleted file mode 100644
index 87ba62de33..00
--- 
a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/ar9_lantiq_easy50810.dts
+++ /dev/null
@@ -1,73 +0,0 @@
-/dts-v1/;
-
-#include "ar9.dtsi"
-
-/ {
-   compatible = "lantiq,easy50810", "lantiq,xway", "lantiq,ar9";
-   model = "Lantiq EASY50810";
-
-   chosen {
-   bootargs = "console=ttyLTQ0,115200";
-   };
-
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x200>;
-   };
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_default>;
-
-   state_default: pinmux {
-   exin {
-   lantiq,groups = "exin1";
-   lantiq,function = "exin";
-   };
-   };
-};
-
- {
-   phy-mode = "rmii";
-};
-
- {
-   flash@0 {
-   compatible = "lantiq,nor";
-   bank-width = <2>;
-   reg = <0 0x0 0x200>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "uboot";
-   reg = <0x0 0x1>; /* 64 KB */
-   };
-
-   partition@1 {
-   label = "uboot_env";
-   reg = <0x1 0x1>; /* 64 KB */
-   };
-
-   partition@2 {
-   label = "firmware";
-   reg = <0x2 0x3d>;
-   };
-
-   partition@40 {
-   label = "rootfs";
-   reg = <0x40 0x40>;
-   };
-   };
-   };
-};
-
- {
-   status = "okay";
-   lantiq,shadow = <0xfff>;
-   lantiq,groups = <0x3>;
-};
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 2/4] build: image: add SOC device variable

2019-12-16 Thread Adrian Schmutzler 
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 a/include/image.mk b/include/image.mk
index 8592c19b99..26da4d6819 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -420,6 +420,7 @@ define Device/Init
   DEVICE_DTS :=
   DEVICE_DTS_CONFIG :=
   DEVICE_DTS_DIR :=
+  SOC :=
 
   BOARD_NAME :=
   UIMAGE_NAME :=
@@ -437,7 +438,7 @@ DEFAULT_DEVICE_VARS := \
   DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE KERNEL_SIZE \
   CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI BLOCKSIZE PAGESIZE SUBPAGESIZE \
   VID_HDR_OFFSET UBINIZE_OPTS UBINIZE_PARTS MKUBIFS_OPTS DEVICE_DTS \
-  DEVICE_DTS_CONFIG DEVICE_DTS_DIR BOARD_NAME UIMAGE_NAME SUPPORTED_DEVICES \
+  DEVICE_DTS_CONFIG DEVICE_DTS_DIR SOC BOARD_NAME UIMAGE_NAME 
SUPPORTED_DEVICES \
   IMAGE_METADATA KERNEL_ENTRY KERNEL_LOADADDR UBOOT_PATH DEVICE_VENDOR \
   DEVICE_MODEL DEVICE_VARIANT \
   DEVICE_ALT0_VENDOR DEVICE_ALT0_MODEL DEVICE_ALT0_VARIANT \
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH 0/4] lantiq: use soc_vendor_device scheme on DTS file

2019-12-16 Thread Adrian Schmutzler 
** 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
https://github.com/openwrt/openwrt/pull/2216
(this patchset is based on them, but they are not included in the set;
they are added in the referenced staging tree, though)

The state in my tree is build-tested on all subtargets, but should be
run-tested at least on 1-3 selected devices.

If Acked, I will change the ATH_SOC, MTK_SOC and SUNXI_SOC variables to
SOC as well when applying this patchset.

Adrian Schmutzler (4):
  lantiq: split device definitions into files
  build: image: add SOC device variable
  lantiq: use soc_vendor_device scheme on DTS file
  lantiq: remove ar9_lantiq_easy50810.dts

 include/image.mk  |   3 +-
 .../files/arch/mips/boot/dts/EASY50810.dts|  73 --
 .../mips/boot/dts/{ => lantiq}/amazonse.dtsi  |   0
 .../amazonse_allnet_all0333cj.dts}|   0
 .../amazonse_netgear_dgn1000b.dts}|   0
 .../arch/mips/boot/dts/{ => lantiq}/ar9.dtsi  |   0
 .../ar9_avm_fritz7312.dts}|   0
 .../ar9_avm_fritz7320.dts}|   0
 .../ar9_bt_homehub-v3a.dts}   |   0
 .../ar9_buffalo_wbmr-hp-g300h.dts}|   0
 .../ar9_netgear_dgn3500.dts}  |   2 +-
 .../ar9_netgear_dgn3500.dtsi} |   0
 .../ar9_netgear_dgn3500b.dts} |   2 +-
 .../{H201L.dts => lantiq/ar9_zte_h201l.dts}   |   0
 .../ar9_zyxel_p-2601hn.dts}   |   0
 .../mips/boot/dts/{ => lantiq}/danube.dtsi|   0
 .../danube_arcadyan_arv4510pw.dts}|   0
 .../danube_arcadyan_arv4518pwr01.dts} |   2 +-
 .../danube_arcadyan_arv4518pwr01.dtsi}|   0
 .../danube_arcadyan_arv4518pwr01a.dts}|   2 +-
 .../danube_arcadyan_arv4519pw.dts}|   0
 .../danube_arcadyan_arv4520pw.dts}|   0
 .../danube_arcadyan_arv4525pw.dts}|   0
 .../danube_arcadyan_arv452cqw.dts}|   0
 .../danube_arcadyan_arv7506pw11.dts}  |   0
 .../danube_arcadyan_arv7510pw22.dts}  |   0
 .../danube_arcadyan_arv7518pw.dts}|   0
 .../danube_arcadyan_arv7519pw.dts}|   0
 .../danube_arcadyan_arv7525pw.dts}|   0
 .../danube_arcadyan_arv752dpw.dts}|   0
 .../danube_arcadyan_arv752dpw22.dts}  |   0
 .../danube_arcadyan_arv8539pw22.dts}  |   0
 .../danube_audiocodes_mp-252.dts} |   0
 .../danube_bt_homehub-v2b.dts}|   0
 .../danube_lantiq_easy50712.dts}  |   0
 .../danube_siemens_gigaset-sx76x.dts} |   0
 .../mips/boot/dts/{ => lantiq}/falcon.dtsi|   0
 .../falcon_lantiq_easy88388.dts}  |   2 +-
 .../falcon_lantiq_easy88444.dts}  |   2 +-
 .../falcon_lantiq_easy98000-nand.dts} |   2 +-
 .../falcon_lantiq_easy98000-nor.dts}  |   2 +-
 .../falcon_lantiq_easy98000-sflash.dts}   |   4 +-
 .../falcon_lantiq_easy98000.dtsi} |   0
 .../falcon_lantiq_easy98020-v18.dts}  |   2 +-
 .../falcon_lantiq_easy98020.dts}  |   2 +-
 .../falcon_lantiq_easy98021.dts}  |   2 +-
 .../falcon_lantiq_easy98035synce.dts} |   2 +-
 .../falcon_lantiq_easy98035synce1588.dts} |   2 +-
 .../falcon_lantiq_falcon-mdu.dts} |   2 +-
 .../falcon_lantiq_falcon-sfp.dts} |   2 +-
 .../falcon_sflash-16m.dtsi}   |   0
 .../arch/mips/boot/dts/{ => lantiq}/vr9.dtsi  |   0
 .../vr9_alphanetworks_asl56026.dts}   |   0
 .../vr9_arcadyan_arv7519rw22.dts} |   0
 .../vr9_arcadyan_vg3503j.dts} |   0
 .../vr9_arcadyan_vgv7510kw22-brn.dts} |   2 +-
 .../vr9_arcadyan_vgv7510kw22-nor.dts} |   2 +-
 .../vr9_arcadyan_vgv7510kw22.dtsi}|   0
 .../vr9_arcadyan_vgv7519-brn.dts} |   2 +-
 .../vr9_arcadyan_vgv7519-nor.dts} |   2 +-
 .../vr9_arcadyan_vgv7519.dtsi}|   0
 .../vr9_avm_fritz3370-rev2-hynix.dts} |   2 +-
 .../vr9_avm_fritz3370-rev2-micron.dts}|   2 +-
 .../vr9_avm_fritz3370-rev2.dtsi}  |   0
 .../vr9_avm_fritz7360sl.dts}  |   2 +-
 .../vr9_avm_fritz7362sl.dts}  |   2 +-
 .../vr9_avm_fritz736x.dtsi}   |   0
 .../vr9_avm_fritz7412.dts}|   0
 .../vr9_bt_homehub-v5a.dts}   |   0
 .../vr9_buffalo_wbmr-300hpd.dts}  |   0
 .../vr9_lantiq_easy80920-nand.dts}|   2 +-
 .../vr9_lantiq_easy80920-nor.dts} |   2 +-
 .../vr9_lantiq_easy80920.dtsi}|   0
 .../vr9_netgear_dm200.dts}|   0
 .../vr9_tplink_tdw8970.dts}   |   2 +-
 .../vr9_tplink_tdw8980.dts}   |   2 +-

Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices

2019-12-16 Thread Alberto Bursi 



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:
   so there is some value
in supporting these devices, especially if someone else does all the work
for it.


These are wifi/network testing equipment, not network devices.

Also I don't see the value in "saving some money" by using a bit less RAM

when the cheaper system is sold for 3k, and most stuff is above 10k.

You could use standard whitebox x86 stuff at that price point.

-Alberto


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