Re: [PATCH] uqmi: wms - added storage to read text messages
Yes, that's a good proposal. I will send an updated patch for review tomorrow.
Henrik
Den mån 14 mars 2022 kl 21:39 skrev Sergey Ryazanov :
>
> On Mon, Mar 14, 2022 at 9:03 PM Henrik Ginstmark wrote:
> > Yes, I agree this will break backward compatibility. --get-message and
> > --delete-message should be quite easy to fix with still have SIM as
> > default storage, but for --list-messages I don´t have a clear view how
> > to add an optional argument, jet.
> > A quick fix could be just to add a new command: --list-messages-me.
>
> How about implementing the storage argument as an option for each of
> these commands? Like the SMSC option for the send message command.
> Something like this:
> --list-messages: List SMS messages
> --messages-storage : Messages storage (sim (default), me)
> --delete-message :Delete SMS message at index
> --messages-storage : Messages storage (sim (default), me)
> --get-message : Get SMS message at index
> --messages-storage : Messages storage (sim (default), me)
>
> > Den mån 14 mars 2022 kl 01:26 skrev Sergey Ryazanov
> > :
> >> Hello Henrik,
> >>
> >> On Sun, Mar 13, 2022 at 10:25 PM Henrik Ginstmark
> >> wrote:
> >>> Today it's hard coded to read text messages from SIM card.
> >>> Not all devices store received text messages in SIM, they store
> >>> in me, QMI_WMS_STORAGE_TYPE_NV.
> >>> I have added a switch to choose sim or me for --list-messages,
> >>> --get-message and --delete-message.
> >>>
> >>> Signed-off-by: Henrik Ginstmarh
> >>> ---
> >>> uqmi/src/commands-wms.c | 69 +
> >>> uqmi/src/commands-wms.h | 10 +++---
> >>> 2 files changed, 61 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
> >>> index a58fd6a..2bcc398 100644
> >>> --- a/uqmi/src/commands-wms.c
> >>> +++ b/uqmi/src/commands-wms.c
> >>> @@ -46,6 +46,14 @@ cmd_wms_list_messages_prepare(struct qmi_dev *qmi,
> >>> struct qmi_request *req, stru
> >>> QMI_INIT(message_tag,
> >>> QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
> >>> };
> >>>
> >>> + if (strcmp(arg, "sim") == 0) {
> >>> + } else if (strcmp(arg, "me") == 0) {
> >>> + qmi_set_ptr(, storage_type, QMI_WMS_STORAGE_TYPE_NV);
> >>> + } else {
> >>> + uqmi_add_error("Invalid value (sim or me)");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> +
> >>> qmi_set_wms_list_messages_request(msg, );
> >>>
> >>> return QMI_CMD_REQUEST;
> >>> @@ -283,20 +291,37 @@ static void blobmsg_add_hex(struct blob_buf *buf,
> >>> const char *name, unsigned con
> >>> static enum qmi_cmd_result
> >>> cmd_wms_delete_message_prepare(struct qmi_dev *qmi, struct qmi_request
> >>> *req, struct qmi_msg *msg, char *arg)
> >>> {
> >>> - char *err;
> >>> - int id;
> >>> -
> >>> - id = strtoul(arg, , 10);
> >>> - if (err && *err) {
> >>> - uqmi_add_error("Invalid message ID");
> >>> - return QMI_CMD_EXIT;
> >>> - }
> >>> -
> >>> static struct qmi_wms_delete_request mreq = {
> >>> QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
> >>> QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
> >>> };
> >>>
> >>> + char *s;
> >>> + int id;
> >>> +
> >>> + s = strchr(arg, ',');
> >>> + if (!s) {
> >>> + uqmi_add_error("Invalid argument");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> + s = strtok(s, ",");
> >>> + if (!s) {
> >>> + uqmi_add_error("No message id");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> + id = strtoul(s, , 0);
> >>> + if (s && *s) {
> >>> + uqmi_add_error("Invalid message id");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> + if (strcmp(strtok(arg, ","), "sim") == 0) {
> >>> + } else if (strcmp(strtok(arg, ","), "me") == 0) {
> >>> + qmi_set_ptr(, memory_storage,
> >>> QMI_WMS_STORAGE_TYPE_NV);
> >>> + } else {
> >>> + uqmi_add_error("Invalid value (sim or me)");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> +
> >>> mreq.set.memory_index = 1;
> >>> mreq.data.memory_index = id;
> >>>
> >>> @@ -449,12 +474,30 @@ cmd_wms_get_message_prepare(struct qmi_dev *qmi,
> >>> struct qmi_request *req, struct
> >>> ),
> >>> QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
> >>> };
> >>> - char *err;
> >>> +
> >>> + char *s;
> >>> int id;
> >>>
> >>> - id = strtoul(arg, , 10);
> >>> - if (err && *err) {
> >>> - uqmi_add_error("Invalid message ID");
> >>> + s = strchr(arg, ',');
> >>> + if (!s) {
> >>> + uqmi_add_error("Invalid argument");
> >>> + return
Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS
On 3/14/22 06:56, Birger Koblitz wrote: Hi, CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms. This is because only on those platforms there is hardware support for an SMBus controller which is used for the MDIO of the SFP ports. If we had known about the worning, then we would have tried to fix it by making CONFIG_SFP only on the 93xx platforms dependent on CONFIG_MDIO_SMBUS. How to do this is however not clear to me. We should probably remove the dependency to CONFIG_MDIO_SMBUS from CONFIG_SFP. This is added in target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch You could add the dependency to the CONFIG_I2C_RTL9300 in target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: wms - added storage to read text messages
On Mon, Mar 14, 2022 at 9:03 PM Henrik Ginstmark wrote:
> Yes, I agree this will break backward compatibility. --get-message and
> --delete-message should be quite easy to fix with still have SIM as
> default storage, but for --list-messages I don´t have a clear view how
> to add an optional argument, jet.
> A quick fix could be just to add a new command: --list-messages-me.
How about implementing the storage argument as an option for each of
these commands? Like the SMSC option for the send message command.
Something like this:
--list-messages: List SMS messages
--messages-storage : Messages storage (sim (default), me)
--delete-message :Delete SMS message at index
--messages-storage : Messages storage (sim (default), me)
--get-message : Get SMS message at index
--messages-storage : Messages storage (sim (default), me)
> Den mån 14 mars 2022 kl 01:26 skrev Sergey Ryazanov :
>> Hello Henrik,
>>
>> On Sun, Mar 13, 2022 at 10:25 PM Henrik Ginstmark
>> wrote:
>>> Today it's hard coded to read text messages from SIM card.
>>> Not all devices store received text messages in SIM, they store
>>> in me, QMI_WMS_STORAGE_TYPE_NV.
>>> I have added a switch to choose sim or me for --list-messages,
>>> --get-message and --delete-message.
>>>
>>> Signed-off-by: Henrik Ginstmarh
>>> ---
>>> uqmi/src/commands-wms.c | 69 +
>>> uqmi/src/commands-wms.h | 10 +++---
>>> 2 files changed, 61 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
>>> index a58fd6a..2bcc398 100644
>>> --- a/uqmi/src/commands-wms.c
>>> +++ b/uqmi/src/commands-wms.c
>>> @@ -46,6 +46,14 @@ cmd_wms_list_messages_prepare(struct qmi_dev *qmi,
>>> struct qmi_request *req, stru
>>> QMI_INIT(message_tag, QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
>>> };
>>>
>>> + if (strcmp(arg, "sim") == 0) {
>>> + } else if (strcmp(arg, "me") == 0) {
>>> + qmi_set_ptr(, storage_type, QMI_WMS_STORAGE_TYPE_NV);
>>> + } else {
>>> + uqmi_add_error("Invalid value (sim or me)");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> +
>>> qmi_set_wms_list_messages_request(msg, );
>>>
>>> return QMI_CMD_REQUEST;
>>> @@ -283,20 +291,37 @@ static void blobmsg_add_hex(struct blob_buf *buf,
>>> const char *name, unsigned con
>>> static enum qmi_cmd_result
>>> cmd_wms_delete_message_prepare(struct qmi_dev *qmi, struct qmi_request
>>> *req, struct qmi_msg *msg, char *arg)
>>> {
>>> - char *err;
>>> - int id;
>>> -
>>> - id = strtoul(arg, , 10);
>>> - if (err && *err) {
>>> - uqmi_add_error("Invalid message ID");
>>> - return QMI_CMD_EXIT;
>>> - }
>>> -
>>> static struct qmi_wms_delete_request mreq = {
>>> QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
>>> QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
>>> };
>>>
>>> + char *s;
>>> + int id;
>>> +
>>> + s = strchr(arg, ',');
>>> + if (!s) {
>>> + uqmi_add_error("Invalid argument");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + s = strtok(s, ",");
>>> + if (!s) {
>>> + uqmi_add_error("No message id");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + id = strtoul(s, , 0);
>>> + if (s && *s) {
>>> + uqmi_add_error("Invalid message id");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + if (strcmp(strtok(arg, ","), "sim") == 0) {
>>> + } else if (strcmp(strtok(arg, ","), "me") == 0) {
>>> + qmi_set_ptr(, memory_storage, QMI_WMS_STORAGE_TYPE_NV);
>>> + } else {
>>> + uqmi_add_error("Invalid value (sim or me)");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> +
>>> mreq.set.memory_index = 1;
>>> mreq.data.memory_index = id;
>>>
>>> @@ -449,12 +474,30 @@ cmd_wms_get_message_prepare(struct qmi_dev *qmi,
>>> struct qmi_request *req, struct
>>> ),
>>> QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
>>> };
>>> - char *err;
>>> +
>>> + char *s;
>>> int id;
>>>
>>> - id = strtoul(arg, , 10);
>>> - if (err && *err) {
>>> - uqmi_add_error("Invalid message ID");
>>> + s = strchr(arg, ',');
>>> + if (!s) {
>>> + uqmi_add_error("Invalid argument");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + s = strtok(s, ",");
>>> + if (!s) {
>>> + uqmi_add_error("No message id");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + id = strtoul(s, , 0);
>>> + if (s && *s) {
>>> + uqmi_add_error("Invalid message id");
>>> + return QMI_CMD_EXIT;
>>> + }
>>> + if (strcmp(strtok(arg, ","), "sim")
Re: [PATCH] kernel: enable SERIAL_8250_16550A_VARIANTS
Hi, Stijn, On Mon, 14 Mar 2022 at 19:59, Stijn Tintel wrote: > > Kernel 5.6 introduced a new config symbol SERIAL_8250_16550A_VARIANTS. > In kernel 5.8, this symbol was changed to default to on on !x86, as some > embedded devices still use 16650A variants. Let's play safe here and > enable this symbol in the generic config, to avoid others from running > into this problem and having to spend several hours trying to bisect > this problem. While we could disable the symbol in the x86 target > configs, a 20ms boot time reduction really isn't worth the time wasted > on bisecting this issue. > > Matt discovered this problem while working on adding support for the > WatchGuard Firebox M200 to the qoriq target, where it caused some > characters to be missing on the console output. > > Reported-by: Matt Fawcett > Signed-off-by: Stijn Tintel [patch snipped] Seems sensible to me. Reviewed-by: Rui Salvaterra Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: enable SERIAL_8250_16550A_VARIANTS
Kernel 5.6 introduced a new config symbol SERIAL_8250_16550A_VARIANTS. In kernel 5.8, this symbol was changed to default to on on !x86, as some embedded devices still use 16650A variants. Let's play safe here and enable this symbol in the generic config, to avoid others from running into this problem and having to spend several hours trying to bisect this problem. While we could disable the symbol in the x86 target configs, a 20ms boot time reduction really isn't worth the time wasted on bisecting this issue. Matt discovered this problem while working on adding support for the WatchGuard Firebox M200 to the qoriq target, where it caused some characters to be missing on the console output. Reported-by: Matt Fawcett Signed-off-by: Stijn Tintel --- target/linux/generic/config-5.10 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index ca93b5f269..5f762529f0 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -5313,7 +5313,7 @@ CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_SENSORS_XGENE is not set # CONFIG_SENSORS_ZL6100 is not set CONFIG_SERIAL_8250=y -# CONFIG_SERIAL_8250_16550A_VARIANTS is not set +CONFIG_SERIAL_8250_16550A_VARIANTS=y # CONFIG_SERIAL_8250_ACCENT is not set # CONFIG_SERIAL_8250_ASPEED_VUART is not set # CONFIG_SERIAL_8250_BOCA is not set -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] command-nas: fix json output
Hey everyone,
I attached the current output of my patched uqmi.
Please let me know if you think the arrays should be named differently
or if you spot an error.
Thanks and have a nice day
Aiyion
On 3/8/22 16:01, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells",
"geran" entries as an array called alike,
and wrap output for different "frequencies" as such.
Reported-by: Cezary Jackiewicz
Suggested-by: Oskari Lemmelä
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari and Cezary,
Please have a thorough look at this, as I do not have the matching
equipment at hand to test all cases.
Let me know if you rather would see `frequencies` become `channels`
and if the `geran`-array does make sense.
I just compiled this series without errors and will have a look at the
LTE-related json-outputs.
Thanks for your time
Jan-Niklas
commands-nas.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 275c53f..b99767f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.primary_scrambling_code);
blobmsg_add_u32(, "rscp", res.data.umts_info_v2.rscp);
blobmsg_add_u32(, "ecio", res.data.umts_info_v2.ecio);
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j < res.data.umts_info_v2.cell_n; j++) {
cell = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -734,6 +735,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "ecio",
res.data.umts_info_v2.cell[j].ecio);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
+ geran = blobmsg_open_array(, "geran");
for (j = 0; j < res.data.umts_info_v2.neighboring_geran_n; j++)
{
cell = blobmsg_open_table(, "neighboring_geran");
blobmsg_add_u32(, "channel",
@@ -746,6 +749,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.neighboring_geran[j].rssi);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, geran);
blobmsg_close_table(, c);
}
if (res.set.intrafrequency_lte_info_v2) {
@@ -769,6 +773,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,11 +785,14 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
- if (res.data.interfrequency_lte_info.frequency_n > 0)
+ if (res.data.interfrequency_lte_info.frequency_n > 0) {
c = blobmsg_open_table(,
"interfrequency_lte_info");
+ frequencies = blobmsg_open_array(,
"frequencies");
+ }
for (i = 0; i < res.data.interfrequency_lte_info.frequency_n;
i++) {
freq = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -795,6 +803,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+
Re: Drop CONFIG_IPV6 ?
On 14/03/2022 01:31, Etienne Champetier wrote: > Hi All, > > We currently have some circular dependencies caused by the usage of > PROVIDES and @IPV6 > https://github.com/openwrt/openwrt/issues/9407 > > One radical way to fix, suggested by Jow, is to completely remove > CONFIG_IPV6 from OpenWrt. > This would also allow to simplify packaging of some core components. > > Is anyone disabling CONFIG_IPV6 ? Not me > Do people agree we can drop CONFIG_IPV6 ? Yes > Should we do this before we branch 22.x ? As we're already in a feature freeze, no. Thanks, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
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 --- Hi, Is anyone disabling CONFIG_IPV6 ? no. Do people agree we can drop CONFIG_IPV6 ? yes. Should we do this before we branch 22.x ? Yes --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
IPv6 is not a "nice to have" think. If you are using OpenWrt and consider IPv6 a nice to have thing you should do some reading and network understanding as it seems it lacks some very fundamental one to you. I see people often complaining they don't get IPv6 from their ISPs and what is the way they expect to do ? Disabling IPv6 on their builds. Certainly not. On 14/03/2022 03:08, Reiner Karlsberg wrote: Practically always I disable IPv6. First of all, to get rid of stuff, which might be "nice to have", but is not required "to do the job". The less code I have running, the smaller the probability to run into bugs. Second, it is a good method to reduce the requirements on flash, when having many non-standard packages installed, i.e. squid or PHP. Third, I often have to connect via wireless WANs, not supporting IPv6 at all. So, pls do _not_ remove CONFIG_IPV6 Cheers, Reiner ___ 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: Drop CONFIG_IPV6 ?
Hi, > Is anyone disabling CONFIG_IPV6 ? no. > Do people agree we can drop CONFIG_IPV6 ? yes. > Should we do this before we branch 22.x ? yes please. I am tired of sprinkling ifdefs, maintaining separate package build flavors, conditional dependency forests and runtime checks for IPv6 presence everywhere. Even if it is decided to leave CONFIG_IPV6 in place I'll probably stop respecing it for things like uhttpd, rpcd, LuCI etc. soon since I consider builds with CONFIG_IPV6=n to be an unsupported configuration. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
Hi, Etienne, On Sun, 13 Mar 2022 at 23:33, Etienne Champetier wrote: > > We currently have some circular dependencies caused by the usage of > PROVIDES and @IPV6 > https://github.com/openwrt/openwrt/issues/9407 These don't seem unfixable. > One radical way to fix, suggested by Jow, is to completely remove > CONFIG_IPV6 from OpenWrt. Please, don't. > This would also allow to simplify packaging of some core components. > > Is anyone disabling CONFIG_IPV6 ? Yes. > Do people agree we can drop CONFIG_IPV6 ? No. Fix the dependencies instead, please. IPv6 is already enabled by default in the official builds. People stuck with crappy IPv4-only ISPs and doing their own builds will definitely be pissed off if they find out their kernels were magically bloated for no reason. Thanks, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Drop CONFIG_IPV6 ?
Hi, I am not one of the core devs, but I don't see a point in disabling IPv6 in 2022. Since 21.02 4/32 MB devices aren't viable anymore, can somebody comment on whats the actual size reduction cause I don't see that helping to squeeze stuff like PHP, etc that somebody mentioned? Even if your ISP doesn't provide IPv6 (Mine doesn't as well), I don't see the downside of having IPv6 support. I am pro ease of maintenance instead of the dependency mess that now has to exist. Regards, Robert On Mon, 14 Mar 2022 at 07:15, Reiner Karlsberg wrote: > > Practically always I disable IPv6. First of all, to get rid of stuff, which > might be "nice to have", but is not required > "to do the job". The less code I have running, the smaller the probability to > run into bugs. > Second, it is a good method to reduce the requirements on flash, when having > many non-standard packages installed, i.e. > squid or PHP. > Third, I often have to connect via wireless WANs, not supporting IPv6 at all. > > So, pls do _not_ remove CONFIG_IPV6 > > Cheers, > > Reiner > > > ___ > 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: Drop CONFIG_IPV6 ?
Practically always I disable IPv6. First of all, to get rid of stuff, which might be "nice to have", but is not required "to do the job". The less code I have running, the smaller the probability to run into bugs. Second, it is a good method to reduce the requirements on flash, when having many non-standard packages installed, i.e. squid or PHP. Third, I often have to connect via wireless WANs, not supporting IPv6 at all. So, pls do _not_ remove CONFIG_IPV6 Cheers, Reiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS
Hi,
CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms.
This is because only on those platforms there is hardware support for an SMBus
controller which is used for the MDIO of the SFP ports.
If we had known about the worning, then we would have tried to fix it by
making CONFIG_SFP only on the 93xx platforms dependent on CONFIG_MDIO_SMBUS.
How to do this is however not clear to me.
Cheers,
Birger
On 13.03.22 20:47, Hauke Mehrtens wrote:
> CONFIG_SFP depends on CONFIG_MDIO_SMBUS now and this depends on
> CONFIG_I2C_SMBUS. Activate the missing kernel compile options.
>
> This fixes the following warning:
> WARNING: unmet direct dependencies detected for MDIO_SMBUS
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y] &&
> I2C_SMBUS [=n]
> Selected by [y]:
> - SFP [=y] && NETDEVICES [=y] && PHYLIB [=y] && I2C [=y] && PHYLINK [=y] &&
> (HWMON [=y] || HWMON [=y]=n)
>
> Fixes: 45053b507c66 ("realtek: Add support for SFP EEPROM-access over SMBus")
> Signed-off-by: Hauke Mehrtens
> ---
> target/linux/realtek/rtl838x/config-5.10 | 2 ++
> target/linux/realtek/rtl839x/config-5.10 | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/target/linux/realtek/rtl838x/config-5.10
> b/target/linux/realtek/rtl838x/config-5.10
> index 8e27af95ba46..16964d94c967 100644
> --- a/target/linux/realtek/rtl838x/config-5.10
> +++ b/target/linux/realtek/rtl838x/config-5.10
> @@ -90,6 +90,7 @@ CONFIG_I2C_GPIO=y
> CONFIG_I2C_MUX=y
> # CONFIG_I2C_RTL9300 is not set
> # CONFIG_I2C_MUX_RTL9300 is not set
> +CONFIG_I2C_SMBUS=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_IRQCHIP=y
> CONFIG_IRQ_DOMAIN=y
> @@ -107,6 +108,7 @@ CONFIG_MDIO_BUS=y
> CONFIG_MDIO_DEVICE=y
> CONFIG_MDIO_DEVRES=y
> CONFIG_MDIO_I2C=y
> +CONFIG_MDIO_SMBUS=y
> CONFIG_MEMFD_CREATE=y
> CONFIG_MFD_SYSCON=y
> CONFIG_MIGRATION=y
> diff --git a/target/linux/realtek/rtl839x/config-5.10
> b/target/linux/realtek/rtl839x/config-5.10
> index 5704b4265a3c..b3192d1866da 100644
> --- a/target/linux/realtek/rtl839x/config-5.10
> +++ b/target/linux/realtek/rtl839x/config-5.10
> @@ -86,6 +86,7 @@ CONFIG_I2C_BOARDINFO=y
> CONFIG_I2C_GPIO=y
> # CONFIG_I2C_RTL9300 is not set
> # CONFIG_I2C_MUX_RTL9300 is not set
> +CONFIG_I2C_SMBUS=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_IRQCHIP=y
> CONFIG_IRQ_DOMAIN=y
> @@ -104,6 +105,7 @@ CONFIG_MDIO_BUS=y
> CONFIG_MDIO_DEVICE=y
> CONFIG_MDIO_DEVRES=y
> CONFIG_MDIO_I2C=y
> +CONFIG_MDIO_SMBUS=y
> CONFIG_MEMFD_CREATE=y
> CONFIG_MFD_SYSCON=y
> CONFIG_MIGRATION=y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
