Re: [PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Hello Zhijun,
On Sat, May 14, 2022 at 8:24 AM Zhijun You wrote:
> Glad to see there's someone else working on encap offload.
> Can confirm it works on my NETGEAR R7800 (QCA9984) with
> ath10k + firmware 10.4-3.9.0.2-00159
> Feel free to add my tested by tag.
>
> Tested-by: Zhijun You
Thank you! Will keep this tag in subsequent formal patch submission.
> I have a few questions though.
>
> In patch 081
>
>> +- ieee80211_tx_status(htt->ar->hw, msdu);
>> ++ memset(&status, 0, sizeof(status));
>>
>
> Instead of using memset maybe we could just init status like this?
> struct ieee80211_tx_status status = {};
Yep, this is possible. But what will this change? The initialization
on declaration will make the code one line shorter, but we will lose
the grouping. When the buffer is initialized just before use, it
becomes clear that it does not carry any additional information. Only
what is filled right now. So, I prefer to keep memset() at its
location until there are some performance issues.
> In the original patch [1] proposed by QCA guys
Thanks for pointing to the earlier work. I was not aware of it, and
did all the work from scratch using ath11k as a reference :)
> there are extra checks in ath10k_htt_tx_32
>
>> - if ((ieee80211_is_action(hdr->frame_control) ||
>> -ieee80211_is_deauth(hdr->frame_control) ||
>> -ieee80211_is_disassoc(hdr->frame_control)) &&
>> -ieee80211_has_protected(hdr->frame_control)) {
>> - skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
>> - } else if (!(skb_cb->flags & ATH10K_SKB_F_NO_HWCRYPT) &&
>> - txmode == ATH10K_HW_TXRX_RAW &&
>> - ieee80211_has_protected(hdr->frame_control)) {
>> - skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
>> + if (!(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP)) {
>> + if ((ieee80211_is_action(hdr->frame_control) ||
>> +ieee80211_is_deauth(hdr->frame_control) ||
>> +ieee80211_is_disassoc(hdr->frame_control)) &&
>> +ieee80211_has_protected(hdr->frame_control)) {
>> + skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
>> + } else if (!(skb_cb->flags & ATH10K_SKB_F_NO_HWCRYPT) &&
>> + txmode == ATH10K_HW_TXRX_RAW &&
>> + ieee80211_has_protected(hdr->frame_control)) {
>> + skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
>> + }
>>
Nice catch! This code should already support the Ethernet
encapsulated frames according to the switch below this code block. So
this should probably be fixed with a separate patch. I will add it to
the series.
> and in ath10k_offchan_tx_work
>
>> + info = IEEE80211_SKB_CB(skb);
>> + if (info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) {
>> + peer_addr = skb->data;
>> + } else {
>> + hdr = (struct ieee80211_hdr *)skb->data;
>> + peer_addr = ieee80211_get_DA(hdr);
>>
mac80211 will not send offchannel frames with Ethernet encapsulation.
So this check is odd.
> Maybe we should add them back since both are checking for ethernet frames?
>
> 1.
> https://patchwork.kernel.org/project/linux-wireless/patch/20191216092207.31032-1-j...@phrozen.org/
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Hello Oldřich and Edward, Thank you once more for testing these changes. I additionally tested QCA6174 and now I am ready to send a formal patch. May I use your 'tested-by' in subsequent submissions? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [sdwalker/sdwalker.github.io] 2bdb42: This week's update
Hello Jeffery, On Fri, May 13, 2022 at 2:03 AM Jeffery To wrote: > On Fri, May 13, 2022 at 6:26 AM Sergey Ryazanov > wrote: >> >> +1 >> >> Stephan, may I sincerely ask you to stop spamming the list? >> >> On Mon, May 9, 2022 at 12:08 PM wrote: >>> is the below weekly message of any informational value to _all_? can >>> someone maybe block this if it's not? ..thanks ede >>> >>> On 08.05.2022 23:05, Stephen Walker via openwrt-devel wrote: >>>> 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. > > As a package maintainer, I want to know that uscan is running > correctly. These emails are relevant to me. Nice to hear that someone is actually using this information. May I ask why these notifications are directed to the mailing list that is dedicated for development talks? Such a notification just _looks_ irrelevant to some thread, it is not even a patchwork notification or a buildbot warning that is sent as a reply to a patch. > It would be very simple to set up any competent email client to filter > out these messages, if you so choose. It is a matter of balance. Everyone is happy to read these notifications, but someone will not need them and will create an automatic filtering rule. Or someone found these notifications useful, but everyone else wonders why they received them. Is it possible to reconfigure these notifications to send them directly to your mailbox? Or maybe set up a dedicated mailing list? We already have the mailing list for commit notifications. I am subscribed and quite happy to be informed of development progress this way - it saves me a lot of time and does not bother people who prefer some other monitoring approach. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [sdwalker/sdwalker.github.io] 2bdb42: This week's update
+1 Stephan, may I sincerely ask you to stop spamming the list? On Mon, May 9, 2022 at 12:08 PM wrote: > is the below weekly message of any informational value to _all_? can someone > maybe block this if it's not? ..thanks ede > > On 08.05.2022 23:05, Stephen Walker via openwrt-devel wrote: >> 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. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Hello Edward, On Wed, May 11, 2022 at 12:04 AM Edward Matijevic wrote: > Tested on a TP-Link Archer C2600 (IPQ8064 + QCA9980), using official > 22.03-rc1 and your patch on top of 22.03 > Load average peaks were still the same but with the offloading 1min > avg wasn't changing as sharply as without offload > My download speed was a bit more stable with the offload, tested with > a game download from Steam(20+ GB) maintaining over 40MB/s when it'd > only sometimes peak over 40. > Bufferbloat(from Waveform) latency testing wasn't noticeably > different(maybe a slight improvement to minimums), without SQM on > both. > > No obvious regressions but haven't run the patch long enough yet to see issues Thank you for testing and this detailed report. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Hello Oldřich, On Sat, May 7, 2022 at 9:27 AM Oldřich Jedlička wrote: > .Hi Sergey, > > pá 29. 4. 2022 v 3:36 odesílatel Sergey Ryazanov > napsal: >> >> Frame encapsulation from Ethernet into the IEEE 802.11 frame format >> takes a considerable host CPU time on the xmit path. The firmware is >> able to do this operation for us, so enable encapsulation offloading for >> AP and Sta interface types to improve overall system performance. >> >> On a QCA9563+QCA9888-based access point in bridged mode, encapsulation >> offloading increases TCP 16-streams DL throughput from 365 to 396 mbps >> (+8%) and UDP DL throughput from 436 to 483 mbps (+11%). >> >> This change contains a backported series sent upstream [1] and an >> additional patch that enables encapsulation offloading by default. >> >> The new feature has been extensively tested with QCA9888 and works well. >> Kalle has no objections agains the code, but the lack of tests with >> other chips prevents it from being merged [1]. So the improvement is >> still in the RFC/RFT state. >> >> Brave testers who would like to improve the performance of their systems >> and report their results are welcome :) >> >> 1. >> https://lore.kernel.org/ath10k/20220402153615.9593-1-ryazanov@gmail.com/ >> > > I am using your patch for two days. I am not able to tell whether it > does anything with regards to speed (I have not done any performance > tests for comparison), but at least it does not break the internet > connection, which is good :-) > > Tested on Archer C7 v4 (2x) and v5 (2x), both versions contain QCA9563 > + QCA9880. Too many thanks for testing it! -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RFC/RFT] ath10k: use xmit encapsulation offloading
Frame encapsulation from Ethernet into the IEEE 802.11 frame format
takes a considerable host CPU time on the xmit path. The firmware is
able to do this operation for us, so enable encapsulation offloading for
AP and Sta interface types to improve overall system performance.
On a QCA9563+QCA9888-based access point in bridged mode, encapsulation
offloading increases TCP 16-streams DL throughput from 365 to 396 mbps
(+8%) and UDP DL throughput from 436 to 483 mbps (+11%).
This change contains a backported series sent upstream [1] and an
additional patch that enables encapsulation offloading by default.
The new feature has been extensively tested with QCA9888 and works well.
Kalle has no objections agains the code, but the lack of tests with
other chips prevents it from being merged [1]. So the improvement is
still in the RFC/RFT state.
Brave testers who would like to improve the performance of their systems
and report their results are welcome :)
1. https://lore.kernel.org/ath10k/20220402153615.9593-1-ryazanov@gmail.com/
Signed-off-by: Sergey Ryazanov
---
...1-ath10k-improve-tx-status-reporting.patch | 55 ++
...-ath10k-turn-rawmode-into-frame_mode.patch | 72 +++
...add-encapsulation-offloading-support.patch | 186 ++
...calibration-data-via-nvmem-subsystem.patch | 10 +-
...21-ath10k_init_devices_synchronously.patch | 2 +-
.../930-ath10k_add_tpt_led_trigger.patch | 4 +-
...rolling-support-for-various-chipsets.patch | 16 +-
...75-ath10k-use-tpt-trigger-by-default.patch | 2 +-
...h10k-Try-to-get-mac-address-from-dts.patch | 2 +-
...-encapsulation-offloading-by-default.patch | 11 ++
10 files changed, 342 insertions(+), 18 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath10k/081-ath10k-improve-tx-status-reporting.patch
create mode 100644
package/kernel/mac80211/patches/ath10k/082-ath10k-turn-rawmode-into-frame_mode.patch
create mode 100644
package/kernel/mac80211/patches/ath10k/083-ath10k-add-encapsulation-offloading-support.patch
create mode 100644
package/kernel/mac80211/patches/ath10k/991-ath10k-use-encapsulation-offloading-by-default.patch
diff --git
a/package/kernel/mac80211/patches/ath10k/081-ath10k-improve-tx-status-reporting.patch
b/package/kernel/mac80211/patches/ath10k/081-ath10k-improve-tx-status-reporting.patch
new file mode 100644
index 00..1a0915a460
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath10k/081-ath10k-improve-tx-status-reporting.patch
@@ -0,0 +1,55 @@
+From 018de7ad86697d2924677a2a7725331561c03fe0 Mon Sep 17 00:00:00 2001
+From: Sergey Ryazanov
+Date: Sat, 2 Apr 2022 02:37:34 +0300
+Subject: [PATCH RFC 1/3] ath10k: improve tx status reporting
+
+We use ieee80211_tx_status() to report each completed tx frame.
+Internally, this function calls sta_info_get_by_addrs(), what has a
+couple of drawbacks:
+1. additional station lookup causes a performance degradation;
+2. mac80211 can not properly account Ethernet encapsulated frames due
+ to the inability to properly determine the destination (station) MAC
+ address since ieee80211_tx_status() assumes the frame has a 802.11
+ header.
+
+The latter is especially destructive if we want to use hardware frames
+encapsulation.
+
+To fix both of these issues, replace ieee80211_tx_status() with
+ieee80211_tx_status_ext() call and feed it station pointer from the tx
+queue associated with the transmitted frame.
+
+Tested-on: QCA9888 hw 2.0 10.4-3.9.0.2-00131
+Signed-off-by: Sergey Ryazanov
+---
+ drivers/net/wireless/ath/ath10k/txrx.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
+@@ -43,6 +43,7 @@ out:
+ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
+const struct htt_tx_done *tx_done)
+ {
++ struct ieee80211_tx_status status;
+ struct ath10k *ar = htt->ar;
+ struct device *dev = ar->dev;
+ struct ieee80211_tx_info *info;
+@@ -128,7 +129,16 @@ int ath10k_txrx_tx_unref(struct ath10k_h
+ info->status.is_valid_ack_signal = true;
+ }
+
+- ieee80211_tx_status(htt->ar->hw, msdu);
++ memset(&status, 0, sizeof(status));
++ status.skb = msdu;
++ status.info = info;
++
++ rcu_read_lock();
++ if (txq && txq->sta)
++ status.sta = txq->sta;
++ ieee80211_tx_status_ext(htt->ar->hw, &status);
++ rcu_read_unlock();
++
+ /* we do not own the msdu anymore */
+
+ return 0;
diff --git
a/package/kernel/mac80211/patches/ath10k/082-ath10k-turn-rawmode-into-frame_mode.patch
b/package/kernel/mac80211/patches/ath10k/082-ath10k-turn-rawmode-into-frame_mode.patch
new file mode 100644
index 00..db82d236ff
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath10k/082-ath10k-turn-rawmode-into-frame_mode.patch
@@ -0,0 +1,72 @@
+From 4843b08e42794f7405efabb73d20
Re: [PATCH v2] uqmi: wms - added storage to read text messages
On Wed, Apr 13, 2022 at 10:35 AM Henrik Ginstmark wrote: > Den tis 15 mars 2022 kl 21:14 skrev Sergey Ryazanov : >> On Tue, Mar 15, 2022 at 10:36 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 --storage as an argumet available to >>> --list-messages >>> --get-message >>> --delete-message >>> --get-raw-message >>> >>> If --storage is omitted default storage is sim, as before. >>> >>> Signed-off-by: Henrik Ginstmark >> >> Looks good! >> >> Reviewed-by: Sergey Ryazanov > > Hi > What will be the next step? Any testing needed? Patch is good, next step should be applying, but possibly core devs just overlook it. Daniel, do you have any objections with applying this change? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: wms - added storage to read text messages
On Tue, Mar 15, 2022 at 10:36 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 --storage as an argumet available to > --list-messages > --get-message > --delete-message > --get-raw-message > > If --storage is omitted default storage is sim, as before. > > Signed-off-by: Henrik Ginstmark Looks good! Reviewed-by: Sergey Ryazanov ___ 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(&mreq, 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, &mreq);
>>>
>>> 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, &err, 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, &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(&mreq, 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;
>>>
>&
Re: Drop CONFIG_IPV6 ?
Hello Etienne, On Mon, Mar 14, 2022 at 2:36 AM Etienne Champetier wrote: > 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 ? Yep. In many countries (e.g. in Russia) there are almost no ISPs with IPv6, so from time to time I disable IPv6 support in custom builds. Also, disabling IPv6 support saves some storage space on resource constrained devices (e.g. whole ath25 target). > Do people agree we can drop CONFIG_IPV6 ? I do not think it is a good idea to drop this option today. > Should we do this before we branch 22.x ? -- Sergey ___ 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
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(&mreq, 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, &mreq);
>
> 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, &err, 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, &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(&mreq, 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, &err, 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, &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(&mreq, message_memory_storage_id.storage_type,
> QMI_WMS_STORAGE_TYPE_NV);
> + } else {
> + uqmi_add_error("Invalid value (sim or me)");
> return QMI_CMD_EXIT;
> }
>
> diff --git a/uqmi/src/commands-wms.h b/uqmi/src/commands-wms.h
> index e28b97b..d79acd6 100644
> --- a/uqmi/src/commands-wms.h
> +++ b/uqmi/src/commands-wms.h
> @@ -20,7 +20,7 @@
> */
>
> #define __uqmi_wms_commands \
> - __uqmi_command(wms_list_messages, list-messages, no,
> QMI_SERVICE_WMS), \
> + __uqmi_command(wms_list_messages, list-messages, required,
> QMI_SERVICE_WMS), \
> __uqmi_command(wms_delete_message, delete-message, required,
> QMI_SERVICE_WMS), \
> __uqmi_command(wms_get_message, get-message, required,
> QMI_SERVICE_WMS), \
> __uqmi_command(wms_get_raw_message, get-raw-message, required,
> QMI_SERVICE_WMS), \
> @@ -30,10 +30,10 @@
> __uqmi_command(wms_send_message, send-message, required,
> QMI_SERVICE_WMS)
>
> #define wms_helptext \
> - " --lis
DMARC issues (ex. Re: ath9k: support for Extreme Networks AP3805i)
Hello Eugenio, On Tue, Mar 8, 2022 at 12:25 PM Eugenio Tampieri via openwrt-devel wrote: > 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. > > > -- Forwarded message -- > From: Eugenio Tampieri > To: Sergey Ryazanov > Cc: OpenWrt Development List > Bcc: > Date: Tue, 08 Mar 2022 09:20:08 + > Subject: Re: ath9k: support for Extreme Networks AP3805i >> Hello Eugenio, >> >> On Sat, Feb 26, 2022 at 1:22 PM Eugenio Tampieri via openwrt-devel >> wrote: >>> >>> 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. >> >> Please consider configuring the DMARC DNS record properly for mailing >> lists usage, it is quite annoying to reply to a message that was >> wrapped to another message by the mailing list software. > > I have switched this mailing list to my p=none alias that should trick > mailman (at least, according > to its docs) into not applying DMARC workarounds. Let me know if that worked > or not. Still receiving wrapped messages. You can check how the mailing list process your messages in the mailing list archive: https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg61680.html -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: add support for Mikrotik SXT-R LTE
Hello Mike,
On Fri, Mar 4, 2022 at 9:54 PM mk 378 wrote:
> This adds support for the Mikrotik SXT-R LTE device, which is an
> outdoor router that hosts an LTE modem mini PCIe card for its WAN
> connection. The LTE antenna system claims a 9 dBi gain.
>
> Hardware:
> - SoC: QCA9531
> - Flash: 16 MiB SPI NOR
> - RAM: 64 MiB DDR2
> - WiFi: None (no antenna is connected to the SoC WiFi system)
> - Ethernet: 2 x 10/100 Mb.
> - PoE: Passive or 802.3af in on port 1. Unit must be powered by PoE.
>GPIO switchable passive PoE out on port 2.
> - Modem support: Mini PCIe slot wired only for USB2, no PCIe bus.
>Dual LTE antennas, two MicroSIM slots-- SIM card in use is
>selected by a GPIO output. GPIO control of the 3.3 volt power
>to the slot, and hardware control pins 22 and 20.
> - Serial: There is a set of 10 test pads on board near the flash chip.
>Pin 6 is RX and pin 7 is Tx. Tx GPIO pin is shared with the
>yellow LED on the eth1 socket. This DTS sets it as serial
>output for OpenWrt. The bootloader does not use serial.
> - LEDs: Power, LTE, 2x Ethernet Link, PoE out, 5x LTE signal level
> - Buttons: Reset, Mode
>
> Installation: Standard MikroTik-- RouterBOOT netboot the OpenWrt
> initramfs image, then flash the sysupgrade image from within OpenWrt.
> Under OpenWrt, the eth1 port (with PoE in) defaults to be LAN,
> and eth2 is WAN.
>
> Signed-off-by: Mike Keitz
Please, do not mask the email address in the SoB line.
All whitespaces in the patch were mangled, probably by the gmail web
interface. Consider using git-send-email(1) to submit the patch.
> diff --git a/target/linux/ath79/image/mikrotik.mk
> b/target/linux/ath79/image/mikrotik.mk
> index ff3604f2fa..ad29158156 100644
> --- a/target/linux/ath79/image/mikrotik.mk
> +++ b/target/linux/ath79/image/mikrotik.mk
> @@ -64,6 +64,15 @@ define Device/mikrotik_routerboard-sxt-5nd-r2
> endef
> TARGET_DEVICES += mikrotik_routerboard-sxt-5nd-r2
>
> +define Device/mikrotik_routerboard-sxtr
> + $(Device/mikrotik_nor)
> + SOC := qca9531
> + DEVICE_MODEL := RouterBOARD SXTR (SXT-LTE)
> + DEVICE_PACKAGES += kmod-usb2 kmod-gpio-nxp-74hc164
If the only WAN interface is an LTE modem, should the firmware include
a package with a modem driver?
> + IMAGE_SIZE := 16256k
> +endef
> +TARGET_DEVICES += mikrotik_routerboard-sxtr
> +
> define Device/mikrotik_routerboard-wap-g-5hact2hnd
>$(Device/mikrotik_nor)
>SOC := qca9556
> diff --git a/target/linux/ath79/mikrotik/base-files/etc/board.d/01_leds
> b/target/linux/ath79/mikrotik/base-files/etc/board.d/01_leds
> index 25c0184568..1c91c57f38 100644
> --- a/target/linux/ath79/mikrotik/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/mikrotik/base-files/etc/board.d/01_leds
> @@ -32,6 +32,10 @@ mikrotik,routerboard-sxt-5nd-r2)
> ucidef_set_led_rssi "rssimediumhigh" "rssimediumhigh"
> "green:rssimediumhigh" "wlan0" "60" "100"
> ucidef_set_led_rssi "rssihigh" "rssihigh" "green:rssihigh" "wlan0" "80"
> "100"
> ;;
> +mikrotik,routerboard-sxtr)
> +ucidef_set_led_netdev "eth1" "eth1" "green:eth1" "eth1"
> +ucidef_set_led_switch "eth2" "eth2" "green:eth2" "switch0"
> "4" "6" "link tx rx"
> +;;
> esac
>
> board_config_flush
> diff --git a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network
> b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network
> index 1a205e439c..90a018658b 100644
> --- a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network
> @@ -22,6 +22,9 @@ ath79_setup_interfaces()
> mikrotik,routerboard-wapr-2nd)
> ucidef_set_interface_lan "eth0"
> ;;
> +mikrotik,routerboard-sxtr)
> +ucidef_set_interfaces_lan_wan "eth1" "eth0"
> +;;
> *)
> ucidef_set_interfaces_lan_wan "eth0" "eth1"
> ;;
> diff --git a/target/linux/ath79/dts/qca9531_mikrotik_routerboard-sxtr.dts
> b/target/linux/ath79/dts/qca9531_mikrotik_routerboard-sxtr.dts
> new file mode 100644
> index 00..acd8c3e4eb
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_mikrotik_routerboard-sxtr.dts
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "qca9533_mikrotik_routerboard-16m.dtsi"
> +
> +/ {
> + compatible = "mikrotik,routerboard-sxtr", "qca,qca9533";
> + model = "MikroTik RouterBOARD SXTR (SXT-LTE)";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> + led-upgrade = &led_power;
> + led-running = &led_power;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> +
> + led_power: power {
> + label = "green:power";
> + gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + lte {
> + label = "green:lte";
> + gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + eth1green {
> + label = "green:eth1";
> + gpios = <&gpio 2 GPIO_ACTIVE_LOW>;
Re: [PATCH] base-files: call "sync" after initial setup
On Tue, Mar 1, 2022 at 8:51 PM Rafał Miłecki wrote: > OpenWrt uses a lot of (b)ash scripts for initial setup. This isn't the > best solution as they almost never consider syncing files / data. Still > this is what we have and we need to try living with it. > > Without proper syncing OpenWrt can easily get into an inconsistent state > on power cut. It's because: > 1. Actual (flash) inode and data writes are not synchronized > 2. Data writeback can take up to 30 seconds (dirty_expire_centisecs) > 3. ubifs adds extra 5 seconds (dirty_writeback_centisecs) "delay" > > Some possible cases (examples) for new files: > 1. Power cut during 5 seconds after write() can result in all data loss > 2. Power cut happening between 5 and 35 seconds after write() can result >in empty file (inode flushed after 5 seconds, data flush queued) > > Above affects e.g. uci-defaults. After executing some migration script > it may get deleted (whited out) without generated data getting actually > written. Power cut will result in missing data and deleted file. > > There are three ways of dealing with that: > 1. Rewriting all user-space init to proper C with syncs > 2. Trying bash hacks (like creating tmp files & moving them) > 3. Adding sync and hoping for no power cut during critical section > > This change introduces the last solution that is the simplest. It > reduces time during which things may go wrong from ~35 seconds to > probably less than a second. Of course it applies only to IO operations > performed before /etc/init.d/boot . It's probably the stage when the > most new files get created. > > All later changes are usually done using smarter C apps (e.g. busybox or > uci) that creates tmp files and uses rename() that is expected to be > atomic. > > Signed-off-by: Rafał Miłecki Acked-by: Sergey Ryazanov And thank you for such a detailed analysis of the situation! -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubifs: handling dirty data (writing back) + power cuts
Hello Rafał,
On Fri, Feb 25, 2022 at 5:26 PM Rafał Miłecki wrote:
> my system is setup as follows:
>
> # mount | grep ubifs
> /dev/ubi0_1 on /mount/ubifs type ubifs
> (rw,noatime,assert=read-only,ubi=0,vol=1)
>
> # cat /proc/sys/vm/dirty_writeback_centisecs
> 500
> # cat /proc/sys/vm/dirty_expire_centisecs
> 3000
>
> (5 s and 30 s respectively) and I'm currently debugging some data issues
> related to power cuts.
>
>
> My actual problem is related to ubifs behaviour for power cuts happening
> between 5 and 35 seconds after saving a file:
> date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW*
>
> On the next boot test.txt exists but it's EMPTY (file size 0).
>
> For newly created files above behaviour is not the worst one - however
> I'd expect such file to not exist at all.
>
> The biggest problem is when dealing with existing files. In such case
> power cut means loosing it completely. I don't get *old* content nor
> *new* content.
>
>
> I noticed this behaviour with kernel 5.10 and also reproduced it with
> 5.4, 4.14 and 4.4.
>
> Is this a bug or some quirky feature? Can I do anything to avoid such
> situations except modifying all user space to call fsync() when needed?
I experienced a similar issue with F2FS on a x86 board on first boot
after sysupgrade. If the power loss happens within some time window,
then all old configuration files that were extracted from the
sysupgrade.tar archive become empty. Which effectively makes the
device inaccessible via the network.
The best thing I could come up with in that situation is to sync FS
just after the sysupgrade.tar archive extraction, see 880c1f0336
("base-files: prevent issues w/ overlay on powerloss after
sysupgrade"). And according to the documentation Richard pointed out,
this is the only solution from the filesystem developers point of view
- http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath9k: support for Extreme Networks AP3805i
Hello Eugenio, On Sat, Feb 26, 2022 at 1:22 PM Eugenio Tampieri via openwrt-devel wrote: > 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. Please consider configuring the DMARC DNS record properly for mailing lists usage, it is quite annoying to reply to a message that was wrapped to another message by the mailing list software. BTW, use the bottom-posting (https://en.wikipedia.org/wiki/Posting_style), please. All this is boring, let's talk about something more interesting. > -- Forwarded message -- > From: Eugenio Tampieri > To: openwrt-devel@lists.openwrt.org > Date: Sat, 26 Feb 2022 11:08:56 +0100 > Subject: ath9k: support for Extreme Networks AP3805i > Sorry for resubmitting this but yesterday I submitted without a subject... > I'm a CS student and I've used OpenWrt for years. I'm writing to this > mailing list because I'd like to contribute to the project by adding > support of the aformentioned device. > From what I can see, there's already an open PR > (https://github.com/openwrt/openwrt/pull/3762). I've merged the current > master into my fork (https://github.com/eutampieri/openwrt) and I've > built it. I can boot it from ramdisk but as soon as I flash the > sysupgrade I get this into the serial log: > >|Kernel panic - not syncing: No working init found. Try passing init= > option to kernel. See Linux Documentation/admin-guide/init.rst for > guidance.| > As far as I can tell, the init var isn't passed from the bootloader > (uboot), but how can I fix this? If you are running OpenWrt, the message about a missed init executable file means that you had some issues with a rootfs partition. OpenWrt uses the default init path, so there is no need to specify it manually. So if the kernel reports it can not find a working init, then the init was really missed. > Thanks to Benjamin Kallus we've found that the problem may lay here: > > [0.433506] 0x0228-0x03f4 : "firmware" > [0.441125] 2 uimage-fw partitions found on MTD device firmware > [0.447182] Creating 2 MTD partitions on "firmware": > [0.452225] 0x-0x005c : "kernel" > [0.458674] 0x005c-0x01cc : "rootfs" > [0.464437] mtd: device 12 (rootfs) set to be root filesystem > [0.471011] mtdsplit: no squashfs found in "rootfs" > > When I download the mtdblock for rootfs, I get > > > DECIMAL HEXADECIMAL DESCRIPTION > > > 0 0x0 JFFS2 filesystem, big endian > 10223696 0x9C0050Zlib compressed data, compressed > 10224308 0x9C02B4Zlib compressed data, compressed > 10225004 0x9C056CZlib compressed data, compressed It looks like a sysupgrade image you used to flash your device lacks the rootfs part. The JFFS2 signature that you see was written by the firmware on first boot. Check your sysupgrade image with binwalk to make sure. OpenWrt produces several output files, what file exactly did you use to flash the device. Does its name contain the 'squashfs-sysupgrade' suffix? I also noticed that you merged Albinhe's commit to the latest OpenWrt version. Merging can cause unintentional breaking of the firmware image build. Try to build and flash clean unmerged code, possibly just from the Albinhe tree. If the clean version boots successfully, then something went wrong during the merge with the upstream master branch. If the clean version also fails to boot, then a deeper investigation into the build process will be required > Il 25/02/22 14:23, Benjamin Kallus ha scritto: >> That's right; the rootfs doesn't need specific offsets, you just need >> to tell the kernel which partition to use as the rootfs on the kernel >> command line. Good luck getting things working! >> >> On Fri, Feb 25, 2022 at 1:15 PM Eugenio Tampieri >> wrote: >> >> First of all, thanks for your reply. >> Second thing, sorry for the empty subject in my previous email. I >> was caught off guard by the (totally sane and agreeable) rejection >> of multipart HTML emails so I missed the subject. >> >> About the rootfs: I already have the dumps, just not with me. I'll >> try with different offsets. Does the rootfs partition need to have >> a particular label (i.e. rootfs)? I thought that by pointing the >> bootloader to it was enough. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: add support for get operating mode
On Tue, Jan 25, 2022 at 9:13 PM Oskari Lemmela wrote: > Currently only the set operation is supported. > Add support for getting the current operating mode. > > Signed-off-by: Henrik Ginstmark > Signed-off-by: Oskari Lemmela Henrik, Oskari, thank you for taking care of this functionality. Now the patch looks good for me. Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On Wed, Jan 19, 2022 at 1:25 PM Denis Kalashnikov wrote: > On MikroTik RB91x board series a reset key shares SoC gpio > line #15 with NAND ALE and NAND IO7. So we need a custom > gpio driver to manage this non-trivial connection schema. > Also rb91x-nand needs to have an ability to disable a polling > of the key while it works with NAND. > > While we've been integrating rb91x-key into a firmware, we've > figured out that: > * In the gpio-latch driver we need to add a "cansleep" suffix to > several gpiolib calls, > * When gpio-latch and rb91x-nand fail to get a gpio and an error > is -EPROBE_DEFER, they shouldn't report about this, since this > actually is not an error and occurs when the gpio-latch probe > function is called before the rb91x-key probe. > We fix these related things here too. > > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] devices: Add Atheros AR9381
On Wed, Jan 19, 2022 at 2:31 AM Hauke Mehrtens wrote:
> On 1/18/22 23:38, Sergey Ryazanov wrote:
>> On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens wrote:
>>> This adds the Atheros AR9381 to the devices list. This card was found in
>>> the TP-LINK TD-W8970.
>>>
>>> Signed-off-by: Hauke Mehrtens
>>> ---
>>> devices.txt | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/devices.txt b/devices.txt
>>> index e6c18e6..3cec45a 100644
>>> --- a/devices.txt
>>> +++ b/devices.txt
>>> @@ -172,6 +172,7 @@
>>> 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984"
>>> 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887"
>>> 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886"
>>> +0x168c 0xabcd 0x 0x0 0 "Atheros" "AR9381"
>>
>> I am just curious, is this a normal device ID for AR9381 chips or is
>> this some kind of wrongly programmed EEPROM of TD-W8970?
>>
>> ath9k driver knows nothing about the 0xABCD device. And according to
>> wikidevi [1], the normal DevID for AR9381 based devices is 0x0030.
>>
>> 1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02
>>
>
> Hi,
>
> Thanks for pointing this out.
> It could be that I broke something in the EEPROM on this device
> accidentally, I use it for testing since some time. It could also be
> that the PCIe controller driver is broken, it is not upstream and not
> looking nice.
>
> Hauke
>
>
> Here is the output:
> ---
> root@OpenWrt:/# lspci -v -n
> 00:00.0 0604: 1bef:0011 (rev 01) (prog-if 00 [Normal decode])
> Device tree node:
> /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0
> Flags: bus master, fast devsel, latency 0, IRQ 144
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: [disabled]
> Memory behind bridge: 1c00-1c0f [size=1M]
> Prefetchable memory behind bridge: 1c10-1c1f [size=1M]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
> Capabilities: [70] Express Root Port (Slot-), MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Power Budgeting
> Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 0200: 168c:abcd (rev 01)
> Device tree node:
> /sys/firmware/devicetree/base/fpi@1000/pcie@d90/pcie@0/wifi@168c,002e
> Flags: bus master, fast devsel, latency 0, IRQ 144
> Memory at 1c00 (64-bit, non-prefetchable) [size=128K]
> Expansion ROM at 1c10 [virtual] [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
> ---
>
> This is the kernel log:
>
> [ 23.735405] ifx_pcie_bios_map_irq port 0 dev :01:00.0 slot 0 pin 1
> [ 23.740723] ifx_pcie_bios_map_irq dev :01:00.0 irq 144 assigned
> [ 23.746963] ath9k :01:00.0: enabling device ( -> 0002)
> [ 23.753378] ath9k :01:00.0: Direct firmware load for
> ath9k-eeprom-pci-:01:00.0.bin failed with error -2
> [ 23.762891] ath9k :01:00.0: Falling back to sysfs fallback for:
> ath9k-eeprom-pci-:01:00.0.bin
> [ 24.599413] ieee80211 phy0: Atheros AR9300 Rev:3 mem=0xbc00, irq=144
>
Most probably the chip calibration data is Ok, the chip just has no
access to it and utilizes the default DevID value.
Upstream ath9k knows nothing about the 0xABCD device, but our mac80211
package has a special patch for this case:
mac80211 $ grep -rni abcd *
patches/ath9k/513-ath9k_add_pci_ids.patch:17:+#define
AR9300_DEVID_INVALID 0xabcd
patches/ath9k/513-ath9k_add_pci_ids.patch:27:+ { PCI_VDEVICE(ATHEROS,
0xabcd) }, /* PCI-E internal chip default ID */
Commit that introduced the patch has no additional evidences:
mac80211 $ git log -n1 3251cddf31e
commit 3251cddf31efc23089da6f25f97655beaa1f5950
Author: John Crispin
Date: Thu Jul 25 20:28:45 2013 +
mac8021: add ath9k pcie id for AR9381
So I am in doubt. On one hand, 0xABCD is a real ID
Re: [PATCH 1/2] devices: Add Atheros AR9381
Hello Hauke, On Mon, Jan 17, 2022 at 12:35 AM Hauke Mehrtens wrote: > This adds the Atheros AR9381 to the devices list. This card was found in > the TP-LINK TD-W8970. > > Signed-off-by: Hauke Mehrtens > --- > devices.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/devices.txt b/devices.txt > index e6c18e6..3cec45a 100644 > --- a/devices.txt > +++ b/devices.txt > @@ -172,6 +172,7 @@ > 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" > 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" > 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" > +0x168c 0xabcd 0x 0x0 0 "Atheros" "AR9381" I am just curious, is this a normal device ID for AR9381 chips or is this some kind of wrongly programmed EEPROM of TD-W8970? ath9k driver knows nothing about the 0xABCD device. And according to wikidevi [1], the normal DevID for AR9381 based devices is 0x0030. 1. https://wikidevi.wi-cat.ru/Alpha_Networks_WMC-N02 -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On Mon, Jan 17, 2022 at 11:52 AM Denis K wrote: >> I'm seeing this in the bootlogs when using this patch: >> >> [5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517 >> [5.235889] rb91x-nand nand_gpio: failed to get gpios: -517 > > It's okay. The gpio-latch probe function seems to be called before the > rb91x-key probe, but it also returns EPROBE_DEFER (-517), so it will > be called later. Nice catch! Will it be a good idea to avoid printing the error messages from the gpio-latch/rb91x-nand drivers in case of EPROBE_DEFER? Looks like this will help to avoid noise in the dmesg and users confusion. I do not mean doing this immediately in this series, but maybe somedays this will be a welcome change? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Proposed reviewers to include in patches
Hello Mauri, On Mon, Jan 17, 2022 at 5:11 PM Mauri Sandberg wrote: > I sent a patch set for review two months back but I am yet to receive > any comments, ack/nack. Maybe nobody took action since I did not Cc: > anyone specifically. > > Are there ppl who normally carry out reviews or should I just resend the > patch set? Generally, this is a good idea to include people who are involved in a particular component development to the CC list. You could check the committer field of git log --pretty=full to grab a list of involved devs. And even with filled CC, a patch can be overlooked. A month ago I tried to raise a discussion on IRC about a good practice on how to draw some attention to submitted patches. After that discussion I started thinking that most devs are Ok if a submitter "pings" them once a week. So just reply to your initial submission with a "gentle ping" to bump your patch in the list. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On Wed, Jan 12, 2022 at 6:55 PM Koen Vandeputte
wrote:
> On 17.11.21 00:42, Sergey Ryazanov wrote:
>> On Tue, Nov 16, 2021 at 7:07 PM Denis Kalashnikov
>> wrote:
>>> On MikroTik RB91x board series a reset key shares SoC gpio
>>> line #15 with NAND ALE and NAND IO7. So we need a custom
>>> gpio driver to manage this non-trivial connection schema.
>>> Also rb91x-nand needs to have ability to disable a polling
>>> of the key while it works with NAND, and we need to add
>>> "cansleep" suffix to several gpiolib calls in gpio-latch.
>>>
>>> Signed-off-by: Denis Kalashnikov
>> Please find below one nonsignificant nitpick, in all other respects:
>>
>> Reviewed-by: Sergey Ryazanov
>>
>>> +struct gpio_rb91x_key {
>>> + struct gpio_chip gc;
>>> + struct mutex mutex;
>>> + struct mutex poll_mutex;
>> These mutexes are worth a line of documentation. I do not care too
>> much, but if by some other reason you will submit v3, please consider
>> to describe their purpose.
>>
>>> + int polling_disabled;
>>> + struct gpio_desc *gpio;
>>> +};
>
>
> I'm seeing this in the bootlogs when using this patch:
>
> [5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517
> [5.235889] rb91x-nand nand_gpio: failed to get gpios: -517
Looks like gpio-rb91x-key did not provide required GPIO lines.
Could you check whether the driver is built and initialized? Does it
create the gpio controller?
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 3/3] ath25: add kernel 5.10 support
Copy and refresh patches and config from 5.4 to 5.10. Most patches require no more then automatic refresh. The only exception is the Ethernet driver patch, which requires some more work: * drop eth_change_mtu() usage since it was removed from the kernel, it anyway useless for drivers that utilizes alloc_etherdev(); * add the txqueue number argument to the .ndo_tx_timeout callback function; * replace ioremap_nocache() which was finally removed from the kernel by the ioremap() with the same behaviour. Switch target to the new kernel version. Signed-off-by: Sergey Ryazanov --- Changes in v3: * no changes Changes in v2: * add 700-swconfig_mvswitch.patch due to making mvswitch target specific target/linux/ath25/Makefile |2 +- target/linux/ath25/config-5.10| 127 ++ .../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-5.10/108-ar2315_gpio.patch | 363 .../patches-5.10/110-ar2313_ethernet.patch| 1735 + .../ath25/patches-5.10/120-spiflash.patch | 631 ++ .../ath25/patches-5.10/130-watchdog.patch | 277 +++ .../140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-5.10/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-5.10/330-board_leds.patch | 116 ++ .../patches-5.10/700-swconfig_mvswitch.patch | 23 + 14 files changed, 3843 insertions(+), 1 deletion(-) create mode 100644 target/linux/ath25/config-5.10 create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch create mode 100644 target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch create mode 100644 target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch create mode 100644 target/linux/ath25/patches-5.10/700-swconfig_mvswitch.patch diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index 1d8bee507b..df03d9e9fc 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -9,7 +9,7 @@ BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 FEATURES:=squashfs low_mem small_flash -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 define Target/Description Build firmware images for Atheros SoC boards diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 new file mode 100644 index 00..5c983ad82b --- /dev/null +++ b/target/linux/ath25/config-5.10 @@ -0,0 +1,127 @@ +CONFIG_ADM6996_PHY=y +CONFIG_AR2315_WDT=y +CONFIG_AR8216_PHY=y +CONFIG_ARCH_32BIT_OFF_T=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MMAP_RND_BITS_MAX=15 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ATH25=y +CONFIG_BLK_MQ_PCI=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CMDLINE="console=ttyS0,9600 rootfstype=squashfs,jffs2" +CONFIG_CMDLINE_BOOL=y +# CONFIG_CMDLINE_OVERRIDE is not set +# CONFIG_COMMON_CLK is not set +CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CPU_BIG_ENDIAN=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 +CONFIG_CRYPTO_RNG2=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_EARLY_PRINTK=y +CONFIG_ETHERNET_PACKET_MANGLE=y +CONFIG_FORCE_PCI=y +CONFIG_FW_LOADER_PAGED_BUF=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_GETTIMEOFDAY=y +CONFIG_GENERIC_IOMAP=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_LIB_ASHLDI3=y +CONFIG_GENERIC_LIB_ASHRDI3=y +CONFIG_GENERIC_LIB_CMPDI2=y +CONFIG_GENERIC_LIB_LSHRDI3=y +CONFIG_GENERIC_LIB_UCMPDI2=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_AR2315=y +CONFIG_GPIO_AR5312=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +CONFIG_HW_RANDOM=y +CONFIG_HZ_PERIODIC=y +CONFIG_INITRA
[PATCH v3 0/3] ath25: update kernel from 5.4 to 5.10
Hello,
I finally managed to update ath25 to the 5.10 kernel. Sorry for that it
took so long time, I was a quite busy this fall. The update itself is
relatively simple: mostly copy'n'refresh plus a few Ethernet fixes.
Run-time tested with:
* Abicom FreedomCPE (AR5312 based)
* D-Link DWL-2100AP (AR2312 based)
* D-Link DIR-300 (AR2317 based) - WiFi was not tested
I bricked my FON2202 in last year update. Now I have bricked my DIR-300.
Looks like I overwrote the "FIS directory" partition with a too fat
image during sysupgrade. I wonder should the kernel check the partition
boundary before attempting to write outside of it?
Anyway, the new code has not been fully tested against the AR2315 and
AR2317 SoCs and the Marvell 88E6060 switch. Are there any brave testers
here who would like to help test the series with the Fonera 2.0g board?
It should run smoothly, but it is better to be shure.
Changes in v3:
* update the description of the mvswitch moving patch to make it clear
that switching to DSA is possible but not an option for now, thanks to
Bjørn for spotting misguiding description
Changes in v2:
* instead of recovering mvswitch building with v5.10 as a generic
driver, make it ath25 specific in v5.4 and then upgrade the
corresponding patch as usual, thanks Felix for the suggestion
CC: Hauke Mehrtens
CC: Rui Salvaterra
CC: Russell Senior
CC: Bjørn Mork
CC: Stefan Lippers-Hollmann
Sergey Ryazanov (3):
Move mvswitch 88E6060 driver to the ath25
ath25: refresh kernel 5.4 config
ath25: add kernel 5.10 support
target/linux/ath25/Makefile |2 +-
target/linux/ath25/config-5.10| 127 ++
target/linux/ath25/config-5.4 | 56 +-
.../files/drivers/net/phy/mvswitch.c |0
.../files/drivers/net/phy/mvswitch.h |0
.../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++
.../ath25/patches-5.10/108-ar2315_gpio.patch | 363
.../patches-5.10/110-ar2313_ethernet.patch| 1735 +
.../ath25/patches-5.10/120-spiflash.patch | 631 ++
.../ath25/patches-5.10/130-watchdog.patch | 277 +++
.../140-redboot_boardconfig.patch | 60 +
.../141-redboot_partition_scan.patch | 44 +
.../142-redboot_various_erase_size_fix.patch | 72 +
.../ath25/patches-5.10/210-reset_button.patch | 71 +
.../220-enet_micrel_workaround.patch | 111 ++
.../ath25/patches-5.10/330-board_leds.patch | 116 ++
.../patches-5.10/700-swconfig_mvswitch.patch | 23 +
.../patches-5.4/700-swconfig_mvswitch.patch | 23 +
target/linux/generic/config-5.10 |1 -
target/linux/generic/config-5.4 |1 -
.../700-swconfig_switch_drivers.patch |9 +-
21 files changed, 3870 insertions(+), 64 deletions(-)
create mode 100644 target/linux/ath25/config-5.10
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.c (100%)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.h (100%)
create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch
create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch
create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch
create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch
create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch
create mode 100644
target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch
create mode 100644
target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch
create mode 100644
target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch
create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch
create mode 100644
target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch
create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch
create mode 100644 target/linux/ath25/patches-5.10/700-swconfig_mvswitch.patch
create mode 100644 target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/3] ath25: refresh kernel 5.4 config
The target config require some refresh due to the just introduced filtering of the "run-time" options, MIPS eBPF JIT backporting, and so on. The configuration is easily updated using make kernel_oldconfig. So let's update it now in preparation for v5.10 support to reduce the new kernel configuration diff. Signed-off-by: Sergey Ryazanov --- Changes in v3: * no changes Changes in v2: * no changes target/linux/ath25/config-5.4 | 56 ++- 1 file changed, 2 insertions(+), 54 deletions(-) diff --git a/target/linux/ath25/config-5.4 b/target/linux/ath25/config-5.4 index 4b47470699..10b81f0e03 100644 --- a/target/linux/ath25/config-5.4 +++ b/target/linux/ath25/config-5.4 @@ -3,25 +3,10 @@ CONFIG_AR2315_WDT=y CONFIG_AR8216_PHY=y CONFIG_ARCH_32BIT_OFF_T=y CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_PHYS_TO_DMA=y -CONFIG_ARCH_HAS_PTE_SPECIAL=y -CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y -CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MMAP_RND_BITS_MAX=15 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_MEMREMAP_PROT=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ATH25=y CONFIG_BLK_MQ_PCI=y CONFIG_CEVT_R4K=y @@ -42,16 +27,13 @@ CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y CONFIG_CPU_R4K_CACHE_TLB=y CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 CONFIG_CRYPTO_RNG2=y CONFIG_CSRC_R4K=y CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y CONFIG_EARLY_PRINTK=y -CONFIG_EFI_EARLYCON=y CONFIG_ETHERNET_PACKET_MANGLE=y -CONFIG_FONT_8x16=y -CONFIG_FONT_AUTOSELECT=y -CONFIG_FONT_SUPPORT=y CONFIG_FORCE_PCI=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ATOMIC64=y @@ -80,40 +62,6 @@ CONFIG_HARDWARE_WATCHPOINTS=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y -CONFIG_HAVE_ARCH_COMPILER_H=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_ASM_MODVERSIONS=y -CONFIG_HAVE_CBPF_JIT=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FAST_GUP=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_VDSO=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IOREMAP_PROT=y -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PCI=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HW_RANDOM=y CONFIG_HZ_PERIODIC=y CONFIG_INITRAMFS_SOURCE="" @@ -131,10 +79,10 @@ CONFIG_MIGRATION=y CONFIG_MIPS=y CONFIG_MIPS_ASID_BITS=8 CONFIG_MIPS_ASID_SHIFT=0 -CONFIG_MIPS_CBPF_JIT=y CONFIG_MIPS_CLOCK_VSYSCALL=y # CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND is not set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y +CONFIG_MIPS_EBPF_JIT=y CONFIG_MIPS_L1_CACHE_SHIFT=5 CONFIG_MODULES_USE_ELF_REL=y CONFIG_MTD_AR2315=y -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 1/3] Move mvswitch 88E6060 driver to the ath25
ath25 requires a 88E6060 driver to support boards such as Fonera 2.0g
(FON2202). The swconfig based mvswitch driver has not yet been ported to
the 5.10 kernel as the only user is the ath25 target while all other
targets have been switched to the upstream DSA implementation.
Switching ath25 to the DSA implementation is a complex task, since we
need either per-board platform data or DTS support. ath25 lacks both of
them and builds only a signle generic image. So we need to keep the
swconfig driver implementation to easly and quickly port ath25 to the
5.10 kernel.
Since porting the mvswitch driver to 5.10 as a generic driver is not an
option, and since the ath25 is its only user, make mvswitch a target
specific driver to be able to port it to the 5.10 kernel as part of the
kernel version update of the target. This will allow us quickly migrate
to the next kernel version and not delay the next firmware release.
Suggested-by: Felix Fietkau
Signed-off-by: Sergey Ryazanov
---
Changes in v3:
* update the commit message to make it clear that switching to DSA is
possible but not an option for now
Changes in v2:
* new patch; earlier here was another patch that recovers mvswitch
support under the v5.10 kernel
.../files/drivers/net/phy/mvswitch.c | 0
.../files/drivers/net/phy/mvswitch.h | 0
.../patches-5.4/700-swconfig_mvswitch.patch | 23 +++
target/linux/generic/config-5.10 | 1 -
target/linux/generic/config-5.4 | 1 -
.../700-swconfig_switch_drivers.patch | 9 ++--
6 files changed, 25 insertions(+), 9 deletions(-)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.c (100%)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.h (100%)
create mode 100644 target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
diff --git a/target/linux/generic/files/drivers/net/phy/mvswitch.c
b/target/linux/ath25/files/drivers/net/phy/mvswitch.c
similarity index 100%
rename from target/linux/generic/files/drivers/net/phy/mvswitch.c
rename to target/linux/ath25/files/drivers/net/phy/mvswitch.c
diff --git a/target/linux/generic/files/drivers/net/phy/mvswitch.h
b/target/linux/ath25/files/drivers/net/phy/mvswitch.h
similarity index 100%
rename from target/linux/generic/files/drivers/net/phy/mvswitch.h
rename to target/linux/ath25/files/drivers/net/phy/mvswitch.h
diff --git a/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
b/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
new file mode 100644
index 00..7f2c082432
--- /dev/null
+++ b/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
@@ -0,0 +1,23 @@
+--- a/drivers/net/phy/Kconfig
b/drivers/net/phy/Kconfig
+@@ -284,6 +284,10 @@ config IP17XX_PHY
+ tristate "Driver for IC+ IP17xx switches"
+ select SWCONFIG
+
++config MVSWITCH_PHY
++ tristate "Driver for Marvell 88E6060 switches"
++ select ETHERNET_PACKET_MANGLE
++
+ config PSB6970_PHY
+ tristate "Lantiq XWAY Tantos (PSB6970) Ethernet switch"
+ select SWCONFIG
+--- a/drivers/net/phy/Makefile
b/drivers/net/phy/Makefile
+@@ -27,6 +27,7 @@ obj-$(CONFIG_ADM6996_PHY)+= adm6996.o
+ obj-$(CONFIG_AR8216_PHY) += ar8216.o ar8327.o
+ obj-$(CONFIG_SWCONFIG_B53)+= b53/
+ obj-$(CONFIG_IP17XX_PHY) += ip17xx.o
++obj-$(CONFIG_MVSWITCH_PHY)+= mvswitch.o
+ obj-$(CONFIG_PSB6970_PHY) += psb6970.o
+ obj-$(CONFIG_RTL8306_PHY) += rtl8306.o
+ obj-$(CONFIG_RTL8366_SMI) += rtl8366_smi.o
diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 27e3e90488..c37e33b13d 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -3675,7 +3675,6 @@ CONFIG_MULTIUSER=y
# CONFIG_MVMDIO is not set
# CONFIG_MVNETA_BM is not set
# CONFIG_MVSW61XX_PHY is not set
-# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MV_XOR_V2 is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index c452d263c5..1b3f896514 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -3343,7 +3343,6 @@ CONFIG_MULTIUSER=y
# CONFIG_MV643XX_ETH is not set
# CONFIG_MVMDIO is not set
# CONFIG_MVNETA_BM is not set
-# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MV_XOR_V2 is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
b/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
index f30ad81e4e..b954bbb63e 100644
--- a/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
+++ b/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
@@ -12,7 +12,7 @@ Signed-off-by: Felix Fietkau
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
-@@ -250,6 +250,85 @@ config LED_TRIGGER_PHY
+@@ -250,6 +250,81 @@ config LED_TRIGGER_PHY
Re: [PATCH v2 1/3] Move mvswitch 88E6060 driver to the ath25
Hello Stefan, On Sun, Dec 19, 2021 at 12:12 AM Stefan Lippers-Hollmann wrote: > On 2021-12-18, Sergey Ryazanov wrote: >> On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork wrote: >>> Sergey Ryazanov writes: >>>> ath25 can not be switched to the DSA implementation due to lack of the >>>> DTS support. >>> >>> I fully understand and accept that this isn't made a priority. But the >>> explanation is misleading. It's definitely *possible* to use a DSA >>> driver without DTS. There are examples in mainline. So "cannot" is >>> wrong. >> >> Yep, I know that in general a DSA switch can be configured via the >> platform data as any other device. But in this particular case, the >> particular 88E6060 switch support can not be switched to the DSA >> implementation because the DSA implementation does not support >> configuration via the platform data. >> >> I checked the kernel code and the OpenWrt patches and found the only >> board with the 88E6060 switch and this board utilizes DTS for its >> configuration: > > NET_DSA_MV88E6060 has already been used for this device (tl-wr941nd v2/ > v3) in ar71xx, using platform data > > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd.c;hb=refs/heads/openwrt-19.07 > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/config-4.14;h=9a524fae4316caa10431bd6b3b4dadbe8660f14c;hb=refs/heads/openwrt-19.07#l433 > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l324 Thank you. My mistake was that I was looking for a 88E6060 specific structure. Bjorn was kind and explained that a common structure (struct dsa_chip_data) is used to configure the DSA. Your example now completes the picture! The last link should be: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l531 The 324 line contains a code for RB941-2ND, while the code for TL-WR941ND begins on line 531. > so it should be possible for ath25 as well, although the effort might > not be worth it, considering the age and specifications of the target > devices. As it turned out, the kernel switching to the DSA is a relatively simple task in itself. I see a couple additional complications related to the building process, kernel initialization and user experience. To properly support the DSA switch configuration, we need a board model "autodetection" as well as per board image generation. At the moment the ath25 have no framework for these tasks. It produces a single generic image for all boards. So, we need to introduce per board image generation and a kernel code for MIPS machines handling. Also the DSA introduction will seriously disturb the user experience due to the inability to smoothly update the network config. I just recall a lot of talks after migration of other targets. I personally no longer use ath25 devices and have no motivation to deal with this not hard, but complex task. According to annual discussions about the ath25 target decommission [1,2], there are surprisingly a lot of users of these devices. Maybe someone of the active users of these boards would like to get the ball rolling. So our discussion today will be a good starting point for such a brave man :) 1. https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg60168.html 2. https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg54812.html -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/3] Move mvswitch 88E6060 driver to the ath25
On Sat, Dec 18, 2021 at 6:18 PM Bjørn Mork wrote: > Sergey Ryazanov writes: >> But in this particular case, the >> particular 88E6060 switch support can not be switched to the DSA >> implementation because the DSA implementation does not support >> configuration via the platform data. > > Sorry, I missed this part in my previous reply. I could very well be > wrong, but I cannot see anything DT specific in the mv88e6060 driver. It > just calls dsa_register_switch() to load all the config, and that > function supports both platform data and device tree. Ouch! I totally forgot that DSA switches have a common platform data structure (struct dsa_chip_data), and each DSA driver does not have to provide its own configuration structure. In this case, it looks like the ath25 kernel part can be easily switched to the DSA implementation. Now I can see that the patch description does look misguided. And I should say sorry for taking a while to figure that out. If someone of maintainers already took this patch, then please update the commit message. Or I will send the patch with the updated message tomorrow. > But again: I don't expect you (or anyone else) to put a lot of work > into this. Just wanted to paint the bike shed red for christmas ;-) Yes, that was perfectly clear from the first email :) I just wrongly assumed that the mv88e6060 DSA driver can not be used with the platform data. Now you have clearly shown that this is possible. Thanks for this explanation! -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/3] Move mvswitch 88E6060 driver to the ath25
Hello Bjørn, On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork wrote: > Sergey Ryazanov writes: >> ath25 can not be switched to the DSA implementation due to lack of the >> DTS support. > > I fully understand and accept that this isn't made a priority. But the > explanation is misleading. It's definitely *possible* to use a DSA > driver without DTS. There are examples in mainline. So "cannot" is > wrong. Yep, I know that in general a DSA switch can be configured via the platform data as any other device. But in this particular case, the particular 88E6060 switch support can not be switched to the DSA implementation because the DSA implementation does not support configuration via the platform data. I checked the kernel code and the OpenWrt patches and found the only board with the 88E6060 switch and this board utilizes DTS for its configuration: openwrt $ grep -rn 'mv88e6060' build_dir/target-mips_mips32_musl/linux-ath25/linux-5.10.87/arch/ openwrt $ grep -rn 'mv88e6060' target/linux/ target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts:68: compatible = "marvell,mv88e6060"; So, I can not find which example you mean. But I may not have understood your input. Please explain where I made a mistake? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/3] ath25: add kernel 5.10 support
Copy and refresh patches and config from 5.4 to 5.10. Most patches require no more then automatic refresh. The only exception is the Ethernet driver patch, which requires some more work: * drop eth_change_mtu() usage since it was removed from the kernel, it anyway useless for drivers that utilizes alloc_etherdev(); * add the txqueue number argument to the .ndo_tx_timeout callback function; * replace ioremap_nocache() which was finally removed from the kernel by the ioremap() with the same behaviour. Switch target to the new kernel version. Signed-off-by: Sergey Ryazanov --- Changes in v2: * add 700-swconfig_mvswitch.patch due to making mvswitch target specific target/linux/ath25/Makefile |2 +- target/linux/ath25/config-5.10| 127 ++ .../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-5.10/108-ar2315_gpio.patch | 363 .../patches-5.10/110-ar2313_ethernet.patch| 1735 + .../ath25/patches-5.10/120-spiflash.patch | 631 ++ .../ath25/patches-5.10/130-watchdog.patch | 277 +++ .../140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-5.10/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-5.10/330-board_leds.patch | 116 ++ .../patches-5.10/700-swconfig_mvswitch.patch | 23 + 14 files changed, 3843 insertions(+), 1 deletion(-) create mode 100644 target/linux/ath25/config-5.10 create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch create mode 100644 target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch create mode 100644 target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch create mode 100644 target/linux/ath25/patches-5.10/700-swconfig_mvswitch.patch diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index 1d8bee507b..df03d9e9fc 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -9,7 +9,7 @@ BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 FEATURES:=squashfs low_mem small_flash -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 define Target/Description Build firmware images for Atheros SoC boards diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 new file mode 100644 index 00..5c983ad82b --- /dev/null +++ b/target/linux/ath25/config-5.10 @@ -0,0 +1,127 @@ +CONFIG_ADM6996_PHY=y +CONFIG_AR2315_WDT=y +CONFIG_AR8216_PHY=y +CONFIG_ARCH_32BIT_OFF_T=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MMAP_RND_BITS_MAX=15 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ATH25=y +CONFIG_BLK_MQ_PCI=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CMDLINE="console=ttyS0,9600 rootfstype=squashfs,jffs2" +CONFIG_CMDLINE_BOOL=y +# CONFIG_CMDLINE_OVERRIDE is not set +# CONFIG_COMMON_CLK is not set +CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CPU_BIG_ENDIAN=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 +CONFIG_CRYPTO_RNG2=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_EARLY_PRINTK=y +CONFIG_ETHERNET_PACKET_MANGLE=y +CONFIG_FORCE_PCI=y +CONFIG_FW_LOADER_PAGED_BUF=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_GETTIMEOFDAY=y +CONFIG_GENERIC_IOMAP=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_LIB_ASHLDI3=y +CONFIG_GENERIC_LIB_ASHRDI3=y +CONFIG_GENERIC_LIB_CMPDI2=y +CONFIG_GENERIC_LIB_LSHRDI3=y +CONFIG_GENERIC_LIB_UCMPDI2=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_AR2315=y +CONFIG_GPIO_AR5312=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +CONFIG_HW_RANDOM=y +CONFIG_HZ_PERIODIC=y +CONFIG_INITRAMFS_SOURCE=""
[PATCH v2 0/3] ath25: update kernel from 5.4 to 5.10
Hello,
I finally managed to update ath25 to the 5.10 kernel. Sorry for that it
took so long time, I was a quite busy this fall. The update itself is
relatively simple: mostly copy'n'refresh plus a few Ethernet fixes.
Run-time tested with:
* Abicom FreedomCPE (AR5312 based)
* D-Link DWL-2100AP (AR2312 based)
* D-Link DIR-300 (AR2317 based) - WiFi was not tested
I bricked my FON2202 in last year update. Now I have bricked my DIR-300.
Looks like I overwrote the "FIS directory" partition with a too fat
image during sysupgrade. I wonder should the kernel check the partition
boundary before attempting to write outside of it?
Anyway, the new code has not been fully tested against the AR2315 and
AR2317 SoCs and the Marvell 88E6060 switch. Are there any brave testers
here who would like to help test the series with the Fonera 2.0g board?
It should run smoothly, but it is better to be shure.
Changes in v2:
* instead of recovering mvswitch building with v5.10 as a generic
driver, make it ath25 specific in v5.4 and then upgrade the
corresponding patch as usual, thanks Felix for the suggestion
CC: Hauke Mehrtens
CC: Rui Salvaterra
CC: Russell Senior
Sergey Ryazanov (3):
Move mvswitch 88E6060 driver to the ath25
ath25: refresh kernel 5.4 config
ath25: add kernel 5.10 support
target/linux/ath25/Makefile |2 +-
target/linux/ath25/config-5.10| 127 ++
target/linux/ath25/config-5.4 | 56 +-
.../files/drivers/net/phy/mvswitch.c |0
.../files/drivers/net/phy/mvswitch.h |0
.../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++
.../ath25/patches-5.10/108-ar2315_gpio.patch | 363
.../patches-5.10/110-ar2313_ethernet.patch| 1735 +
.../ath25/patches-5.10/120-spiflash.patch | 631 ++
.../ath25/patches-5.10/130-watchdog.patch | 277 +++
.../140-redboot_boardconfig.patch | 60 +
.../141-redboot_partition_scan.patch | 44 +
.../142-redboot_various_erase_size_fix.patch | 72 +
.../ath25/patches-5.10/210-reset_button.patch | 71 +
.../220-enet_micrel_workaround.patch | 111 ++
.../ath25/patches-5.10/330-board_leds.patch | 116 ++
.../patches-5.10/700-swconfig_mvswitch.patch | 23 +
.../patches-5.4/700-swconfig_mvswitch.patch | 23 +
target/linux/generic/config-5.10 |1 -
target/linux/generic/config-5.4 |1 -
.../700-swconfig_switch_drivers.patch |9 +-
21 files changed, 3870 insertions(+), 64 deletions(-)
create mode 100644 target/linux/ath25/config-5.10
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.c (100%)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.h (100%)
create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch
create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch
create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch
create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch
create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch
create mode 100644
target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch
create mode 100644
target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch
create mode 100644
target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch
create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch
create mode 100644
target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch
create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch
create mode 100644 target/linux/ath25/patches-5.10/700-swconfig_mvswitch.patch
create mode 100644 target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/3] Move mvswitch 88E6060 driver to the ath25
The only user of the swconfig-based mvswitch driver is the ath25 target.
All other targets have been switched to the upstream DSA implementation.
ath25 can not be switched to the DSA implementation due to lack of the
DTS support. mvswitch is still required for ath25 to support such boards
as Fonera 2.0g (FON2202). So make it target specific to keep generic
config and patches clean.
Suggested-by: Felix Fietkau
Signed-off-by: Sergey Ryazanov
---
Changes in v2:
* new patch; earlier here was another patch that recovers mvswitch
support under the v5.10 kernel
.../files/drivers/net/phy/mvswitch.c | 0
.../files/drivers/net/phy/mvswitch.h | 0
.../patches-5.4/700-swconfig_mvswitch.patch | 23 +++
target/linux/generic/config-5.10 | 1 -
target/linux/generic/config-5.4 | 1 -
.../700-swconfig_switch_drivers.patch | 9 ++--
6 files changed, 25 insertions(+), 9 deletions(-)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.c (100%)
rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.h (100%)
create mode 100644 target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
diff --git a/target/linux/generic/files/drivers/net/phy/mvswitch.c
b/target/linux/ath25/files/drivers/net/phy/mvswitch.c
similarity index 100%
rename from target/linux/generic/files/drivers/net/phy/mvswitch.c
rename to target/linux/ath25/files/drivers/net/phy/mvswitch.c
diff --git a/target/linux/generic/files/drivers/net/phy/mvswitch.h
b/target/linux/ath25/files/drivers/net/phy/mvswitch.h
similarity index 100%
rename from target/linux/generic/files/drivers/net/phy/mvswitch.h
rename to target/linux/ath25/files/drivers/net/phy/mvswitch.h
diff --git a/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
b/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
new file mode 100644
index 00..7f2c082432
--- /dev/null
+++ b/target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch
@@ -0,0 +1,23 @@
+--- a/drivers/net/phy/Kconfig
b/drivers/net/phy/Kconfig
+@@ -284,6 +284,10 @@ config IP17XX_PHY
+ tristate "Driver for IC+ IP17xx switches"
+ select SWCONFIG
+
++config MVSWITCH_PHY
++ tristate "Driver for Marvell 88E6060 switches"
++ select ETHERNET_PACKET_MANGLE
++
+ config PSB6970_PHY
+ tristate "Lantiq XWAY Tantos (PSB6970) Ethernet switch"
+ select SWCONFIG
+--- a/drivers/net/phy/Makefile
b/drivers/net/phy/Makefile
+@@ -27,6 +27,7 @@ obj-$(CONFIG_ADM6996_PHY)+= adm6996.o
+ obj-$(CONFIG_AR8216_PHY) += ar8216.o ar8327.o
+ obj-$(CONFIG_SWCONFIG_B53)+= b53/
+ obj-$(CONFIG_IP17XX_PHY) += ip17xx.o
++obj-$(CONFIG_MVSWITCH_PHY)+= mvswitch.o
+ obj-$(CONFIG_PSB6970_PHY) += psb6970.o
+ obj-$(CONFIG_RTL8306_PHY) += rtl8306.o
+ obj-$(CONFIG_RTL8366_SMI) += rtl8366_smi.o
diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 27e3e90488..c37e33b13d 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -3675,7 +3675,6 @@ CONFIG_MULTIUSER=y
# CONFIG_MVMDIO is not set
# CONFIG_MVNETA_BM is not set
# CONFIG_MVSW61XX_PHY is not set
-# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MV_XOR_V2 is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index c452d263c5..1b3f896514 100644
--- a/target/linux/generic/config-5.4
+++ b/target/linux/generic/config-5.4
@@ -3343,7 +3343,6 @@ CONFIG_MULTIUSER=y
# CONFIG_MV643XX_ETH is not set
# CONFIG_MVMDIO is not set
# CONFIG_MVNETA_BM is not set
-# CONFIG_MVSWITCH_PHY is not set
# CONFIG_MV_XOR_V2 is not set
# CONFIG_MWAVE is not set
# CONFIG_MWL8K is not set
diff --git a/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
b/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
index f30ad81e4e..b954bbb63e 100644
--- a/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
+++ b/target/linux/generic/hack-5.4/700-swconfig_switch_drivers.patch
@@ -12,7 +12,7 @@ Signed-off-by: Felix Fietkau
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
-@@ -250,6 +250,85 @@ config LED_TRIGGER_PHY
+@@ -250,6 +250,81 @@ config LED_TRIGGER_PHY
for any speed known to the PHY.
@@ -50,10 +50,6 @@ Signed-off-by: Felix Fietkau
+ tristate "Driver for IC+ IP17xx switches"
+ select SWCONFIG
+
-+config MVSWITCH_PHY
-+ tristate "Driver for Marvell 88E6060 switches"
-+ select ETHERNET_PACKET_MANGLE
-+
+config PSB6970_PHY
+ tristate "Lantiq XWAY Tantos (PSB6970) Ethernet switch"
+ select SWCONFIG
@@ -100,7 +96,7 @@ Signed-off-by: Felix Fietkau
config SFP
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
-@@ -22,6 +22,20 @@ libphy-$(CONFIG_LED_TRIGGER_PHY)+= phy_
+@@ -22,6 +22,19 @@ libphy-$(CONFIG_LED_TR
[PATCH v2 2/3] ath25: refresh kernel 5.4 config
The target config require some refresh due to the just introduced filtering of the "run-time" options, MIPS eBPF JIT backporting, and so on. The configuration is easily updated using make kernel_oldconfig. So let's update it now in preparation for v5.10 support to reduce the new kernel configuration diff. Signed-off-by: Sergey Ryazanov --- Changes in v2: * no changes target/linux/ath25/config-5.4 | 56 ++- 1 file changed, 2 insertions(+), 54 deletions(-) diff --git a/target/linux/ath25/config-5.4 b/target/linux/ath25/config-5.4 index 4b47470699..10b81f0e03 100644 --- a/target/linux/ath25/config-5.4 +++ b/target/linux/ath25/config-5.4 @@ -3,25 +3,10 @@ CONFIG_AR2315_WDT=y CONFIG_AR8216_PHY=y CONFIG_ARCH_32BIT_OFF_T=y CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_PHYS_TO_DMA=y -CONFIG_ARCH_HAS_PTE_SPECIAL=y -CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y -CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MMAP_RND_BITS_MAX=15 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_MEMREMAP_PROT=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ATH25=y CONFIG_BLK_MQ_PCI=y CONFIG_CEVT_R4K=y @@ -42,16 +27,13 @@ CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y CONFIG_CPU_R4K_CACHE_TLB=y CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 CONFIG_CRYPTO_RNG2=y CONFIG_CSRC_R4K=y CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y CONFIG_EARLY_PRINTK=y -CONFIG_EFI_EARLYCON=y CONFIG_ETHERNET_PACKET_MANGLE=y -CONFIG_FONT_8x16=y -CONFIG_FONT_AUTOSELECT=y -CONFIG_FONT_SUPPORT=y CONFIG_FORCE_PCI=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ATOMIC64=y @@ -80,40 +62,6 @@ CONFIG_HARDWARE_WATCHPOINTS=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y -CONFIG_HAVE_ARCH_COMPILER_H=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_ASM_MODVERSIONS=y -CONFIG_HAVE_CBPF_JIT=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FAST_GUP=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_VDSO=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IOREMAP_PROT=y -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PCI=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HW_RANDOM=y CONFIG_HZ_PERIODIC=y CONFIG_INITRAMFS_SOURCE="" @@ -131,10 +79,10 @@ CONFIG_MIGRATION=y CONFIG_MIPS=y CONFIG_MIPS_ASID_BITS=8 CONFIG_MIPS_ASID_SHIFT=0 -CONFIG_MIPS_CBPF_JIT=y CONFIG_MIPS_CLOCK_VSYSCALL=y # CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND is not set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y +CONFIG_MIPS_EBPF_JIT=y CONFIG_MIPS_L1_CACHE_SHIFT=5 CONFIG_MODULES_USE_ELF_REL=y CONFIG_MTD_AR2315=y -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] kernel: 5.10: recover 88E6060 switches support
On Fri, Dec 17, 2021 at 12:34 PM Felix Fietkau wrote:
> On 2021-12-17 10:13, Sergey Ryazanov wrote:
>> On Fri, Dec 17, 2021 at 11:52 AM Felix Fietkau wrote:
>>> On 2021-12-16 23:29, Sergey Ryazanov wrote:
>>>> Support for mvswich driver (Marvell 88E6060 switches) build has been
>>>> missed during the initial v5.10 kernel introduction. But it is required
>>>> for AR21xx boards, e.g. Fonera 2.0. Return the missed driver building
>>>> instructions to fix boards support with the new kernel.
>>>>
>>>> Compile tested only with the ath25 target.
>>>>
>>>> Fixes: b10d604459 ("kernel: add linux 5.10 support")
>>>> CC: Felix Fietkau
>>>> Signed-off-by: Sergey Ryazanov
>>>
>>> There is an upstream DSA driver for 88e6060, I think we should try to
>>> use that one instead.
>>
>> ath25 target does not utilize DTS. Without it DSA drivers are almost
>> useless. Almost the single still usable board that is supported by the
>> ath25 target is Fonera 2.0g, which is based on 88e6060. So we still
>> need the mvswitch driver for it.
> In that case, please remove the driver from the generic kernel
> files/patches and move it to ath25 instead.
Ok, will do in V2.
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] kernel: 5.10: recover 88E6060 switches support
On Fri, Dec 17, 2021 at 11:52 AM Felix Fietkau wrote:
> On 2021-12-16 23:29, Sergey Ryazanov wrote:
>> Support for mvswich driver (Marvell 88E6060 switches) build has been
>> missed during the initial v5.10 kernel introduction. But it is required
>> for AR21xx boards, e.g. Fonera 2.0. Return the missed driver building
>> instructions to fix boards support with the new kernel.
>>
>> Compile tested only with the ath25 target.
>>
>> Fixes: b10d604459 ("kernel: add linux 5.10 support")
>> CC: Felix Fietkau
>> Signed-off-by: Sergey Ryazanov
>
> There is an upstream DSA driver for 88e6060, I think we should try to
> use that one instead.
ath25 target does not utilize DTS. Without it DSA drivers are almost
useless. Almost the single still usable board that is supported by the
ath25 target is Fonera 2.0g, which is based on 88e6060. So we still
need the mvswitch driver for it.
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] ath25: refresh kernel 5.4 config
The target config require some refresh due to the just introduced filtering of the "run-time" options, MIPS eBPF JIT backporting, and so on. The configuration is easily updated using make kernel_oldconfig. So let's update it now in preparation for v5.10 support to reduce the new kernel configuration diff. Signed-off-by: Sergey Ryazanov --- target/linux/ath25/config-5.4 | 56 ++- 1 file changed, 2 insertions(+), 54 deletions(-) diff --git a/target/linux/ath25/config-5.4 b/target/linux/ath25/config-5.4 index 4b47470699..10b81f0e03 100644 --- a/target/linux/ath25/config-5.4 +++ b/target/linux/ath25/config-5.4 @@ -3,25 +3,10 @@ CONFIG_AR2315_WDT=y CONFIG_AR8216_PHY=y CONFIG_ARCH_32BIT_OFF_T=y CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_PHYS_TO_DMA=y -CONFIG_ARCH_HAS_PTE_SPECIAL=y -CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y -CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MMAP_RND_BITS_MAX=15 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_MEMREMAP_PROT=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ATH25=y CONFIG_BLK_MQ_PCI=y CONFIG_CEVT_R4K=y @@ -42,16 +27,13 @@ CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y CONFIG_CPU_R4K_CACHE_TLB=y CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 CONFIG_CRYPTO_RNG2=y CONFIG_CSRC_R4K=y CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y CONFIG_EARLY_PRINTK=y -CONFIG_EFI_EARLYCON=y CONFIG_ETHERNET_PACKET_MANGLE=y -CONFIG_FONT_8x16=y -CONFIG_FONT_AUTOSELECT=y -CONFIG_FONT_SUPPORT=y CONFIG_FORCE_PCI=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_GENERIC_ATOMIC64=y @@ -80,40 +62,6 @@ CONFIG_HARDWARE_WATCHPOINTS=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y -CONFIG_HAVE_ARCH_COMPILER_H=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_ASM_MODVERSIONS=y -CONFIG_HAVE_CBPF_JIT=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FAST_GUP=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_VDSO=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IOREMAP_PROT=y -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PCI=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HW_RANDOM=y CONFIG_HZ_PERIODIC=y CONFIG_INITRAMFS_SOURCE="" @@ -131,10 +79,10 @@ CONFIG_MIGRATION=y CONFIG_MIPS=y CONFIG_MIPS_ASID_BITS=8 CONFIG_MIPS_ASID_SHIFT=0 -CONFIG_MIPS_CBPF_JIT=y CONFIG_MIPS_CLOCK_VSYSCALL=y # CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND is not set CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y +CONFIG_MIPS_EBPF_JIT=y CONFIG_MIPS_L1_CACHE_SHIFT=5 CONFIG_MODULES_USE_ELF_REL=y CONFIG_MTD_AR2315=y -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] ath25: add kernel 5.10 support
Copy and refresh patches and config from 5.4 to 5.10. Most patches require no more then automatic refresh. The only exception is the Ethernet driver patch, which requires some more work: * drop eth_change_mtu() usage since it was removed from the kernel, it anyway useless for drivers that utilizes alloc_etherdev(); * add the txqueue number argument to the .ndo_tx_timeout callback function; * replace ioremap_nocache() which was finally removed from the kernel by the ioremap() with the same behaviour. Switch target to the new kernel version. Signed-off-by: Sergey Ryazanov --- target/linux/ath25/Makefile |2 +- target/linux/ath25/config-5.10| 127 ++ .../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-5.10/108-ar2315_gpio.patch | 363 .../patches-5.10/110-ar2313_ethernet.patch| 1735 + .../ath25/patches-5.10/120-spiflash.patch | 631 ++ .../ath25/patches-5.10/130-watchdog.patch | 277 +++ .../140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-5.10/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-5.10/330-board_leds.patch | 116 ++ 13 files changed, 3820 insertions(+), 1 deletion(-) create mode 100644 target/linux/ath25/config-5.10 create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch create mode 100644 target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch create mode 100644 target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index 1d8bee507b..df03d9e9fc 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -9,7 +9,7 @@ BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 FEATURES:=squashfs low_mem small_flash -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 define Target/Description Build firmware images for Atheros SoC boards diff --git a/target/linux/ath25/config-5.10 b/target/linux/ath25/config-5.10 new file mode 100644 index 00..5c983ad82b --- /dev/null +++ b/target/linux/ath25/config-5.10 @@ -0,0 +1,127 @@ +CONFIG_ADM6996_PHY=y +CONFIG_AR2315_WDT=y +CONFIG_AR8216_PHY=y +CONFIG_ARCH_32BIT_OFF_T=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MMAP_RND_BITS_MAX=15 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ATH25=y +CONFIG_BLK_MQ_PCI=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CMDLINE="console=ttyS0,9600 rootfstype=squashfs,jffs2" +CONFIG_CMDLINE_BOOL=y +# CONFIG_CMDLINE_OVERRIDE is not set +# CONFIG_COMMON_CLK is not set +CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CPU_BIG_ENDIAN=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 +CONFIG_CRYPTO_RNG2=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +CONFIG_EARLY_PRINTK=y +CONFIG_ETHERNET_PACKET_MANGLE=y +CONFIG_FORCE_PCI=y +CONFIG_FW_LOADER_PAGED_BUF=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_GETTIMEOFDAY=y +CONFIG_GENERIC_IOMAP=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_LIB_ASHLDI3=y +CONFIG_GENERIC_LIB_ASHRDI3=y +CONFIG_GENERIC_LIB_CMPDI2=y +CONFIG_GENERIC_LIB_LSHRDI3=y +CONFIG_GENERIC_LIB_UCMPDI2=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_AR2315=y +CONFIG_GPIO_AR5312=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +CONFIG_HW_RANDOM=y +CONFIG_HZ_PERIODIC=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_IP17XX_PHY=y +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_MIPS_CPU=y +CONFIG_IRQ_WORK=y +CONFIG_LEDS_GPIO=y +CONFIG_LOCK_DEBUGGING_SUPPORT=y +CONFIG_MDIO_BUS=y +CONFIG_MDIO_DEVICE=y +CONFIG_MDIO_DEVRES=y +C
[PATCH 0/3] ath25: update kernel from 5.4 to 5.10
Hello, I finally managed to update ath25 to the 5.10 kernel. Sorry for that it took so long time, I was a quite busy this fall. The update itself is relatively simple: mostly copy'n'refresh plus a few Ethernet fixes. Run-time tested with: * Abicom FreedomCPE (AR5312 based) * D-Link DWL-2100AP (AR2312 based) * D-Link DIR-300 (AR2317 based) - WiFi was not tested I bricked my FON2202 in last year update. Now I have bricked my DIR-300. Looks like I overwrote the "FIS directory" partition with a too fat image during sysupgrade. I wonder should the kernel check the partition boundary before attempting to write outside of it? Anyway, the new code has not been tested against the AR2315 and AR2317 SoCs and the Marvell 88E6060 switch. Are there any brave testers here who would like to help test the series with the Fonera 2.0g board? It should run smoothly, but it is better to be shure. The series is depend on earlier submitted kernel configuration cleanup patches [1, 2]. The dependency is not strict and the code should build even without it. 1. http://lists.openwrt.org/pipermail/openwrt-devel/2021-December/037387.html 2. http://patchwork.ozlabs.org/project/openwrt/list/?series=277243 CC: Hauke Mehrtens CC: Rui Salvaterra CC: Russell Senior Sergey Ryazanov (3): kernel: 5.10: recover 88E6060 switches support ath25: refresh kernel 5.4 config ath25: add kernel 5.10 support target/linux/ath25/Makefile |2 +- target/linux/ath25/config-5.10| 127 ++ target/linux/ath25/config-5.4 | 56 +- .../ath25/patches-5.10/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-5.10/108-ar2315_gpio.patch | 363 .../patches-5.10/110-ar2313_ethernet.patch| 1735 + .../ath25/patches-5.10/120-spiflash.patch | 631 ++ .../ath25/patches-5.10/130-watchdog.patch | 277 +++ .../140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-5.10/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-5.10/330-board_leds.patch | 116 ++ .../700-swconfig_switch_drivers.patch |9 +- 15 files changed, 3829 insertions(+), 57 deletions(-) create mode 100644 target/linux/ath25/config-5.10 create mode 100644 target/linux/ath25/patches-5.10/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-5.10/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-5.10/120-spiflash.patch create mode 100644 target/linux/ath25/patches-5.10/130-watchdog.patch create mode 100644 target/linux/ath25/patches-5.10/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-5.10/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-5.10/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-5.10/210-reset_button.patch create mode 100644 target/linux/ath25/patches-5.10/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-5.10/330-board_leds.patch -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] kernel: 5.10: recover 88E6060 switches support
Support for mvswich driver (Marvell 88E6060 switches) build has been
missed during the initial v5.10 kernel introduction. But it is required
for AR21xx boards, e.g. Fonera 2.0. Return the missed driver building
instructions to fix boards support with the new kernel.
Compile tested only with the ath25 target.
Fixes: b10d604459 ("kernel: add linux 5.10 support")
CC: Felix Fietkau
Signed-off-by: Sergey Ryazanov
---
.../generic/hack-5.10/700-swconfig_switch_drivers.patch | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/target/linux/generic/hack-5.10/700-swconfig_switch_drivers.patch
b/target/linux/generic/hack-5.10/700-swconfig_switch_drivers.patch
index b90e1fc441..df36e66782 100644
--- a/target/linux/generic/hack-5.10/700-swconfig_switch_drivers.patch
+++ b/target/linux/generic/hack-5.10/700-swconfig_switch_drivers.patch
@@ -12,7 +12,7 @@ Signed-off-by: Felix Fietkau
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
-@@ -61,6 +61,80 @@ config SFP
+@@ -61,6 +61,84 @@ config SFP
depends on HWMON || HWMON=n
select MDIO_I2C
@@ -50,6 +50,10 @@ Signed-off-by: Felix Fietkau
+ tristate "Driver for IC+ IP17xx switches"
+ select SWCONFIG
+
++config MVSWITCH_PHY
++ tristate "Driver for Marvell 88E6060 switches"
++ select ETHERNET_PACKET_MANGLE
++
+config PSB6970_PHY
+ tristate "Lantiq XWAY Tantos (PSB6970) Ethernet switch"
+ select SWCONFIG
@@ -95,7 +99,7 @@ Signed-off-by: Felix Fietkau
config AMD_PHY
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
-@@ -24,6 +24,19 @@ libphy-$(CONFIG_LED_TRIGGER_PHY)+= phy_
+@@ -24,6 +24,20 @@ libphy-$(CONFIG_LED_TRIGGER_PHY)+= phy_
obj-$(CONFIG_PHYLINK) += phylink.o
obj-$(CONFIG_PHYLIB) += libphy.o
@@ -104,6 +108,7 @@ Signed-off-by: Felix Fietkau
+obj-$(CONFIG_AR8216_PHY) += ar8216.o ar8327.o
+obj-$(CONFIG_SWCONFIG_B53)+= b53/
+obj-$(CONFIG_IP17XX_PHY) += ip17xx.o
++obj-$(CONFIG_MVSWITCH_PHY)+= mvswitch.o
+obj-$(CONFIG_PSB6970_PHY) += psb6970.o
+obj-$(CONFIG_RTL8306_PHY) += rtl8306.o
+obj-$(CONFIG_RTL8366_SMI) += rtl8366_smi.o
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] kernel: 5.10: consolidate mac80211 crypto options
Each of
- CRYPTO_AEAD2
- CRYPTO_AEAD
- CRYPTO_GF128MUL
- CRYPTO_GHASH
- CRYPTO_HASH2
- CRYPTO_HASH
- CRYPTO_MANAGER2
- CRYPTO_MANAGER
- CRYPTO_NULL2
either directly required for mac80211 crypto support, or directly
selected by such options. Support for the mac80211 crypto was enabled in
the generic config since c7182123b9 ("kernel: make cryptoapi support
needed by mac80211 built-in"). So move the above options from the target
configs to the generic config to make it clear why do we need them.
CC: Felix Fietkau
Signed-off-by: Sergey Ryazanov
---
target/linux/apm821xx/config-5.10 | 2 --
target/linux/archs38/config-5.10 | 7 ---
target/linux/armvirt/64/config-5.10 | 1 -
target/linux/armvirt/config-5.10 | 7 ---
target/linux/bcm27xx/bcm2708/config-5.10 | 2 --
target/linux/bcm27xx/bcm2709/config-5.10 | 2 --
target/linux/bcm27xx/bcm2710/config-5.10 | 2 --
target/linux/bcm27xx/bcm2711/config-5.10 | 2 --
target/linux/bcm4908/config-5.10 | 2 --
target/linux/bcm53xx/config-5.10 | 2 --
target/linux/bmips/config-5.10| 6 --
target/linux/gemini/config-5.10 | 9 -
target/linux/generic/config-5.10 | 3 ++-
target/linux/imx/config-5.10 | 2 --
target/linux/ipq40xx/config-5.10 | 2 --
target/linux/ipq806x/config-5.10 | 7 ---
target/linux/kirkwood/config-5.10 | 2 --
target/linux/lantiq/config-5.10 | 2 --
target/linux/lantiq/xrx200/config-5.10| 5 -
target/linux/layerscape/armv7/config-5.10 | 2 --
target/linux/layerscape/armv8_64b/config-5.10 | 2 --
target/linux/malta/config-5.10| 7 ---
target/linux/mediatek/mt7622/config-5.10 | 7 ---
target/linux/mediatek/mt7623/config-5.10 | 2 --
target/linux/mediatek/mt7629/config-5.10 | 2 --
target/linux/mpc85xx/config-5.10 | 7 ---
target/linux/mvebu/config-5.10| 7 ---
target/linux/mvebu/cortexa72/config-5.10 | 1 -
target/linux/mxs/config-5.10 | 4
target/linux/octeon/config-5.10 | 7 ---
target/linux/octeontx/config-5.10 | 2 --
target/linux/omap/config-5.10 | 2 --
target/linux/pistachio/config-5.10| 2 --
target/linux/ramips/mt7621/config-5.10| 6 --
target/linux/realtek/config-5.10 | 2 --
target/linux/rockchip/armv8/config-5.10 | 7 ---
target/linux/sunxi/config-5.10| 2 --
target/linux/tegra/config-5.10| 7 ---
target/linux/uml/config-5.10 | 2 --
target/linux/x86/64/config-5.10 | 6 --
target/linux/x86/config-5.10 | 2 --
target/linux/x86/generic/config-5.10 | 5 -
target/linux/zynq/config-5.10 | 2 --
43 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/target/linux/apm821xx/config-5.10
b/target/linux/apm821xx/config-5.10
index 22d34c3fce..a65185a0c0 100644
--- a/target/linux/apm821xx/config-5.10
+++ b/target/linux/apm821xx/config-5.10
@@ -41,14 +41,12 @@ CONFIG_CRC16=y
CONFIG_CRC32_SLICEBY8=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_DEV_PPC4XX=y
-CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1
CONFIG_CRYPTO_LIB_SHA256=y
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_MD5_PPC is not set
-CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
# CONFIG_CRYPTO_SHA1_PPC is not set
diff --git a/target/linux/archs38/config-5.10 b/target/linux/archs38/config-5.10
index af787f887e..5ba3877a64 100644
--- a/target/linux/archs38/config-5.10
+++ b/target/linux/archs38/config-5.10
@@ -71,22 +71,15 @@ CONFIG_COMMON_CLK=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_CPU_RMAP=y
CONFIG_CRC16=y
-CONFIG_CRYPTO_AEAD=y
-CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_ECHAINIV=y
-CONFIG_CRYPTO_HASH=y
-CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_LIB_SHA256=y
-CONFIG_CRYPTO_MANAGER=y
-CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_NULL=y
-CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
diff --git a/target/linux/armvirt/64/config-5.10
b/target/linux/armvirt/64/config-5.10
index 51f3c3c952..27d86cf8a7 100644
--- a/target/linux/armvirt/64/config-5.10
+++ b/target/linux/armvirt/64/config-5.10
@@ -57,7 +57,6 @@ CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA=y
CONFIG_CRYPTO_CHACHA20=y
CONFIG_CRYPTO_CHACHA20_NEON=y
CONFIG_CRYPTO_CRYPTD=y
-CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_GHASH_ARM64_CE=y
CONFIG_CRYPTO_LIB_CHACHA_GENERIC=y
CONFIG_CRYPTO_SHA1=y
diff --git a/target/linux/armvirt/config-5.10 b/target/linux/armvirt/config-5.10
index 6c2255eeb3..c63b169607 100644
--- a/target/linux/armv
[PATCH 1/2] kernel: filter out both Clang and LLD versions
Both CLANG_VERSION and LLD_VERISON are autogenerated runtime configuration options, so add them to the kernel configuration filter and remove from generic and per-target configs to keep configs clean. Signed-off-by: Sergey Ryazanov --- target/linux/armvirt/config-5.10 | 1 - target/linux/at91/sam9x/config-default| 1 - target/linux/at91/sama5/config-default| 1 - target/linux/ath79/config-5.10| 1 - target/linux/bcm27xx/bcm2708/config-5.10 | 1 - target/linux/bcm27xx/bcm2709/config-5.10 | 1 - target/linux/bcm27xx/bcm2710/config-5.10 | 1 - target/linux/bcm27xx/bcm2711/config-5.10 | 1 - target/linux/bcm4908/config-5.10 | 1 - target/linux/bcm53xx/config-5.10 | 1 - target/linux/bcm63xx/config-5.10 | 1 - target/linux/bmips/config-5.10| 1 - target/linux/gemini/config-5.10 | 1 - target/linux/generic/config-5.10 | 1 - target/linux/generic/config-5.4 | 1 - target/linux/generic/config-filter| 2 ++ target/linux/imx/config-5.10 | 1 - target/linux/ipq40xx/config-5.10 | 1 - target/linux/ipq806x/config-5.10 | 1 - target/linux/kirkwood/config-5.10 | 1 - target/linux/lantiq/config-5.10 | 1 - target/linux/layerscape/armv7/config-5.10 | 1 - target/linux/layerscape/armv8_64b/config-5.10 | 1 - target/linux/malta/config-5.10| 1 - target/linux/mediatek/mt7622/config-5.10 | 1 - target/linux/mediatek/mt7623/config-5.10 | 1 - target/linux/mediatek/mt7629/config-5.10 | 1 - target/linux/mpc85xx/config-5.10 | 1 - target/linux/mvebu/config-5.10| 1 - target/linux/mxs/config-5.10 | 1 - target/linux/octeon/config-5.10 | 1 - target/linux/octeontx/config-5.10 | 1 - target/linux/omap/config-5.10 | 1 - target/linux/pistachio/config-5.10| 1 - target/linux/ramips/mt7620/config-5.10| 1 - target/linux/ramips/mt7621/config-5.10| 1 - target/linux/ramips/mt76x8/config-5.10| 1 - target/linux/ramips/rt288x/config-5.10| 1 - target/linux/ramips/rt305x/config-5.10| 1 - target/linux/ramips/rt3883/config-5.10| 1 - target/linux/realtek/config-5.10 | 1 - target/linux/rockchip/armv8/config-5.10 | 1 - target/linux/sunxi/config-5.10| 1 - target/linux/tegra/config-5.10| 1 - target/linux/uml/config-5.10 | 1 - target/linux/x86/config-5.10 | 1 - target/linux/zynq/config-5.10 | 1 - 47 files changed, 2 insertions(+), 46 deletions(-) diff --git a/target/linux/armvirt/config-5.10 b/target/linux/armvirt/config-5.10 index 74b6957d94..6c2255eeb3 100644 --- a/target/linux/armvirt/config-5.10 +++ b/target/linux/armvirt/config-5.10 @@ -91,7 +91,6 @@ CONFIG_IRQ_FORCED_THREADING=y CONFIG_IRQ_WORK=y CONFIG_JBD2=y CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_MEMFD_CREATE=y diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index bd9d106f5b..e3d4c29e99 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -158,7 +158,6 @@ CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y diff --git a/target/linux/at91/sama5/config-default b/target/linux/at91/sama5/config-default index 852e5c95b7..e294fd9e3b 100644 --- a/target/linux/at91/sama5/config-default +++ b/target/linux/at91/sama5/config-default @@ -240,7 +240,6 @@ CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCALVERSION_AUTO=y CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOG_BUF_SHIFT=16 diff --git a/target/linux/ath79/config-5.10 b/target/linux/ath79/config-5.10 index 786d70decf..12f51b08ce 100644 --- a/target/linux/ath79/config-5.10 +++ b/target/linux/ath79/config-5.10 @@ -91,7 +91,6 @@ CONFIG_IRQ_WORK=y CONFIG_LEDS_GPIO=y # CONFIG_LEDS_RESET is not set CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_MDIO_BITBANG=y CONFIG_MDIO_BUS=y diff --git a/target/linux/bcm27xx/bcm2708/config-5.10 b/target/linux/bcm27xx/bcm2708/config-5.10 index 8e8ae51443..aa0b76ad4c 100644 --- a/target/linux/bcm27xx/bcm2708/config-5.10 +++ b/target/linux/bcm27xx/bcm2708/config-5.10 @@ -216,7 +216,6 @@ CONFIG_LEDS_GPIO=y CONFIG_LEDS_TRIGGER_ACTPWR=y CONFIG_LEDS_TRIGGER_INPUT=y CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_CLUT224=y diff --git a/target/linux/bcm27xx/bcm2709/config-5.10 b/target/linux/bcm27xx/bcm2709/config-5.10 index
[PATCH 0/2] kernel: 5.10: configuration cleanup
Hello, this series intended to cleaup per-target kernel configurations. It should reduce amount of odd options in the per-target configurations by removing "run-time" options and moving mac80211 crypto related options to the generic configuration. All this odd options were discovered during the ath25 target migration to the 5.10 kernel (see the next series). Sergey Ryazanov (2): kernel: filter out both Clang and LLD versions kernel: 5.10: consolidate mac80211 crypto options target/linux/apm821xx/config-5.10 | 2 -- target/linux/archs38/config-5.10 | 7 --- target/linux/armvirt/64/config-5.10 | 1 - target/linux/armvirt/config-5.10 | 8 target/linux/at91/sam9x/config-default| 1 - target/linux/at91/sama5/config-default| 1 - target/linux/ath79/config-5.10| 1 - target/linux/bcm27xx/bcm2708/config-5.10 | 3 --- target/linux/bcm27xx/bcm2709/config-5.10 | 3 --- target/linux/bcm27xx/bcm2710/config-5.10 | 3 --- target/linux/bcm27xx/bcm2711/config-5.10 | 3 --- target/linux/bcm4908/config-5.10 | 3 --- target/linux/bcm53xx/config-5.10 | 3 --- target/linux/bcm63xx/config-5.10 | 1 - target/linux/bmips/config-5.10| 7 --- target/linux/gemini/config-5.10 | 10 -- target/linux/generic/config-5.10 | 4 ++-- target/linux/generic/config-5.4 | 1 - target/linux/generic/config-filter| 2 ++ target/linux/imx/config-5.10 | 3 --- target/linux/ipq40xx/config-5.10 | 3 --- target/linux/ipq806x/config-5.10 | 8 target/linux/kirkwood/config-5.10 | 3 --- target/linux/lantiq/config-5.10 | 3 --- target/linux/lantiq/xrx200/config-5.10| 5 - target/linux/layerscape/armv7/config-5.10 | 3 --- target/linux/layerscape/armv8_64b/config-5.10 | 3 --- target/linux/malta/config-5.10| 8 target/linux/mediatek/mt7622/config-5.10 | 8 target/linux/mediatek/mt7623/config-5.10 | 3 --- target/linux/mediatek/mt7629/config-5.10 | 3 --- target/linux/mpc85xx/config-5.10 | 8 target/linux/mvebu/config-5.10| 8 target/linux/mvebu/cortexa72/config-5.10 | 1 - target/linux/mxs/config-5.10 | 5 - target/linux/octeon/config-5.10 | 8 target/linux/octeontx/config-5.10 | 3 --- target/linux/omap/config-5.10 | 3 --- target/linux/pistachio/config-5.10| 3 --- target/linux/ramips/mt7620/config-5.10| 1 - target/linux/ramips/mt7621/config-5.10| 7 --- target/linux/ramips/mt76x8/config-5.10| 1 - target/linux/ramips/rt288x/config-5.10| 1 - target/linux/ramips/rt305x/config-5.10| 1 - target/linux/ramips/rt3883/config-5.10| 1 - target/linux/realtek/config-5.10 | 3 --- target/linux/rockchip/armv8/config-5.10 | 8 target/linux/sunxi/config-5.10| 3 --- target/linux/tegra/config-5.10| 8 target/linux/uml/config-5.10 | 3 --- target/linux/x86/64/config-5.10 | 6 -- target/linux/x86/config-5.10 | 3 --- target/linux/x86/generic/config-5.10 | 5 - target/linux/zynq/config-5.10 | 3 --- 54 files changed, 4 insertions(+), 206 deletions(-) -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT: should the ZBT-WE1206 watchdog be disabled by default?
Hello Arvid, On Wed, Dec 15, 2021 at 2:13 PM Arvid Picciani wrote: > ZBT-WE1206 has an external watchdog that with stock openwrt resets the board. What board do you mean? I am unable to locate ZBT-WE1206 neither in the repository, nor in google. > should this get disabled in bringup or is this considered a downstream > problem? An external watchdog either self-initialized during on power-up or initialized by a bootloader. So there is no such option as disabling it. It is usually sufficient to add a small node to the board DTS file to fully support the external watchdog and avoid unexpected reboots. If a board is supported in the main OpenWrt, then the code should be fixed in it. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 9:57 PM Henrik Ginstmark wrote: > I'm working for a cellular operator and I have the possibilities to monitor > the > registration of the modem from the network side. The registration of an LTE > terminal is clearly described in the 3GPP specifications and I don´t agree > with > the options you mention. An LTE terminal can not register with an invalid APN. Yep. I rechecked the 3GPP TS 23.401 and found that the network may allow APN-less registration for IoT devices, regular modems do not fall into this category. Oops. I should recall these IoT specific stuff earlier. And I am sorry for my mistake. The only thing left to do is to deal with the network responsibility for the default APN (P-GW) providing. The same specification said that a network *should* use a default APN if a registering UE (modem) does not provide any. As someone familiar with the operator business, could you please estimate how many operators do not utilize the default APN feature? > I have created commands for profile modification. But they are not polished ;) > --get-profile-settings : Get APN profile settings (3gpp, 3gpp2),#\n" > \ > --get-default-profile-number : Get default profile number (3gpp, > 3gpp2)\n" \ > --modify-profile ,# Modify profile number (3gpp, 3gpp2)\n" \ > --apn :Use APN\n" \ > --pdp-type ipv4|ipv6|ipv4v6>: Use pdp-type for the connection\n" \ > --username : Use network username\n" \ > --password : Use network password\n" \ > --auth-type pap|chap|both|none: Use network authentication type\n" \ > > > But, if you don't see any benefit with my proposal I´m fine. I should say sorry if my stream of questions looks like an objection against your proposal. The described situation with the inability to register without a preconfigured APN just looks so strange that I can not resist a wish to investigate it :) Moreover, as an occasional LTE modem user, I will be the man who benefits from your work once it is integrated into the uqmi utility. The only thing that worries me is, should we do the default APN reconfiguration (via the airplane mode toggling) automatically in qmi.sh, or should we only provide an ability without forcing it? I am afraid that while trying to automatically solve one rare issue, we unintentionally break a lot of running setups by triggering a modem bug in the airplane mode exiting procedure. Anyway, I am just an occasional project contributor, not from the core developers staff, so you can ignore my thoughts all together ;) > Den sön 5 dec. 2021 kl 18:56 skrev Sergey Ryazanov : >> On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: >>> My intention was to speed up the registration to the LTE network. >> >> If we talk about a modem that is part of a router, then I doubt >> whether the airplane mode activation will be able to speed up the >> registration procedure. After a router power on, the main router >> firmware should complete its own boot process before it will be able >> to switch the modem into airplane mode. But the modem will be powered >> in the same time as the router CPU and most probably the modem will >> boot faster. So when the main firmware becomes ready, the modem will >> be already registered with a network. And triggering the airplane mode >> will only delay data communication readiness. >> >> It would be nice to have the mode configuration command in the uqmi >> utility. But toggling the airplane mode in an automatic fashion can be >> even dangerous (see below). >> >>> When the LTE terminal is powered on it will attach with the modem >>> default APN profile. If that is empty, then the network will assign the >>> network default APN and you get an IP address. >>> >>> But if the modem default APN is incorrect, or if your operator does not >>> assign a default APN, you will be rejected in LTE and the modem will, >>> after a while, register to 3G, since you don´t need a valid APN to >>> register to 3G. >> >> Please be more specific, what modem model and operator do we talk >> about? As I showed earlier, a modem has a lot of options during >> network registration, and earlier community experience suggests that >> it is most probable that a modem will register with a network smoothly >> even without an earlier preconfigured APN. So we should make our >> discussion more specific. >> >>> But if we verify that the modem default APN is correct, before we do the >>> registration, we will be sure that the registration goes smoothly. >>> The modem will store the default APN setting. >> >> When you talking about the defaul
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: > My intention was to speed up the registration to the LTE network. If we talk about a modem that is part of a router, then I doubt whether the airplane mode activation will be able to speed up the registration procedure. After a router power on, the main router firmware should complete its own boot process before it will be able to switch the modem into airplane mode. But the modem will be powered in the same time as the router CPU and most probably the modem will boot faster. So when the main firmware becomes ready, the modem will be already registered with a network. And triggering the airplane mode will only delay data communication readiness. It would be nice to have the mode configuration command in the uqmi utility. But toggling the airplane mode in an automatic fashion can be even dangerous (see below). > When the LTE terminal is powered on it will attach with the modem > default APN profile. If that is empty, then the network will assign the > network default APN and you get an IP address. > > But if the modem default APN is incorrect, or if your operator does not > assign a default APN, you will be rejected in LTE and the modem will, > after a while, register to 3G, since you don´t need a valid APN to > register to 3G. Please be more specific, what modem model and operator do we talk about? As I showed earlier, a modem has a lot of options during network registration, and earlier community experience suggests that it is most probable that a modem will register with a network smoothly even without an earlier preconfigured APN. So we should make our discussion more specific. > But if we verify that the modem default APN is correct, before we do the > registration, we will be sure that the registration goes smoothly. > The modem will store the default APN setting. When you talking about the default APN did you mean the first connection profile? There are only two commands that carry APN: profile creation and network start. Network start should be called after the network registration completion, while the profile configuration command is not yet implemented. > My proposal to qmi.sh, roughly. > > Check PIN > Check data format 802.3/raw-ip > Check modem default APN settings > If the default APN setting are incorrect, > Airplane mode on > Change default APN settings > Airplane mode off This is my primary concern. How many modem models will reliably exit the airplane mode without any issues? > Check operator and radio technology > run --start-network with client_id wds > > I don´t think this will break anything and you can still have > the possibility of adding a secondary APN. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork wrote: > Sergey Ryazanov writes: >> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: >>> Sergey Ryazanov writes: >>>> I am, as an occasional user of an LTE modem, never faced a case when >>>> the modem is unable to register with a network due to an unconfigured >>>> APN. The most prominent fact is that no one else ever faced such case >>>> for a 7 years of the uqmi existence. It looks like you either ran into >>>> a very special operator, or you have a buggy modem that is recovered >>>> via the airplane mode. It is also possible that I do not fully >>>> understand your case. >>> >>> I agree that this is rare. But I'm pretty sure it can happen. >>> >>> A more common case is that the modem picks some arbitrary previously >>> used APN, e.g. profile #1. This will often be fine. But it can be really >>> annoying when it isn't. For example becasue that profile was configured >>> as IPv4 only and you want a dual-stack connection. >> >> Should not a modem reestablish a bearer as soon as a user provides a >> new APN along with the connect QMI command? > > I don't know what a modem should do. I only know what I've observed: If > a modem is attached to a network using an IPv4 only default bearer, then > you cannot connect a dual stack bearer. You can connect it, but you'll > only get the IPv4 part of the session up. And connecting an IPv6 only > APN is impossible in this case. Can you reveal what modem model has such nasty behaviour? I personally test IPv6 with Huawei E3372 (NCM, not QMI) and Sierra MC7304, both of them work stable. But I can not recall whether they established the IPv6 connection as soon as a PDP context was reconfigured or I needed to reattach (power circle) them. Need to recheck someday. And do you remember whether the airplane mode was the only option to configure a new APN or some other operation also help to recover IPv6 connectivity? E.g. disconnect/connect QMI command or a modem power circle. >>> So flight mode will sometimes be necessary when changing APN. >> >> Just to make it clear. Should switching to the airplane mode be a part >> of connection establishing procedure (i.e. qmi.sh script)? Or would it >> be enough to have the mode switching command in the uqmi utility? So a >> user will be able to manually toggle the airplane mode during the APN >> reconfiguration. > > I'm not able to agree with myself here :-) > > On one hand, I believe toggling airplane mode after we know the initial > APN would make this more robust. On the other hand, I fear that kind of > automatic stuff. > > Better leave if for the user as a manual toggle, I guess. You just spelled out all my thoughts :) I am also afraid that such automation will break a lot of modems, since I am not sure how many modem models will reliably exit the airplane mode. And how many models would require workarounds like power circle, etc. >>> Just don't ever force it. We don't want to lose the ability to connect >>> to more than one APN (although this probably isn't supported in uqmi yet >>> since you can't setup QMAP). >> >> Do not understand this phrase. How can the airplane mode break a >> multi-bearer setup? > > I don't know if this was the plan or not. But I feared that someone got > the idea that you could force airplane mode whenever a new APN is > configured. This would obviously break existing connections. Oh, now I got it. Thank you for your clarification. >> BTW, when you are talking about QMAP, did you mean utilizing the QMAP >> demux module from the kernel as it is or implementing the WWAN >> subsystem ops for the qmi_wwan module. In other words, did you mean >> protocol or implementation? > > I was talking about the (lack of) muxing setup support in uqmi. There > is no way to tell the modem firmware how the different channels are > supposed to be connected. Ouch, now I got this too. Whether the --profile option serves this purpose, or do we need to implement some other message? I know this goes beyond the APN change discussion, but since such a case presented itself, I want to ask you a question. What do you think about turning the current linux QMAP implementation into a library and use it within the qmi_wwan driver to implement the data channels demuxing that is controlled via the WWAN ops? I would like to try this, but I have been pointed out a couple of times about the complexity of the Qualcomm protocols, so I am just afraid to propose such a change :) -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: > Sergey Ryazanov writes: >> I am, as an occasional user of an LTE modem, never faced a case when >> the modem is unable to register with a network due to an unconfigured >> APN. The most prominent fact is that no one else ever faced such case >> for a 7 years of the uqmi existence. It looks like you either ran into >> a very special operator, or you have a buggy modem that is recovered >> via the airplane mode. It is also possible that I do not fully >> understand your case. > > I agree that this is rare. But I'm pretty sure it can happen. > > A more common case is that the modem picks some arbitrary previously > used APN, e.g. profile #1. This will often be fine. But it can be really > annoying when it isn't. For example becasue that profile was configured > as IPv4 only and you want a dual-stack connection. Should not a modem reestablish a bearer as soon as a user provides a new APN along with the connect QMI command? > So flight mode will sometimes be necessary when changing APN. Just to make it clear. Should switching to the airplane mode be a part of connection establishing procedure (i.e. qmi.sh script)? Or would it be enough to have the mode switching command in the uqmi utility? So a user will be able to manually toggle the airplane mode during the APN reconfiguration. > Just don't ever force it. We don't want to lose the ability to connect > to more than one APN (although this probably isn't supported in uqmi yet > since you can't setup QMAP). Do not understand this phrase. How can the airplane mode break a multi-bearer setup? BTW, when you are talking about QMAP, did you mean utilizing the QMAP demux module from the kernel as it is or implementing the WWAN subsystem ops for the qmi_wwan module. In other words, did you mean protocol or implementation? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
CC Piotr and Matti to draw some more attention to this case. On Sun, Dec 5, 2021 at 2:19 AM Henrik Ginstmark wrote: > Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov : >> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote: >>> This command make it possible to query if the modem is in flight mode or >>> not. >>> >>> If you need to change your APN setting it should be done during flight mode >>> on. >> >> Just curious, is this true for any Qualcomm based mode or only for a >> specific model? > > When an LTE terminal is powered on it needs a valid APN to be able to > register to the > network. Some cellular operators allow an "empty" APN and then set a default > APN > to the terminal. > The most optimal way to power on an LTE terminal would be with flight mode on, > check that the correct APN is configured and then set flight mode off. > This is for all LTE terminals. Sounds stranger. In the OpenWrt at the moment, APN passed to a modem during the data connection establishment stage. A long time after the modem will be registered with a cell network. uqmi.sh script even has a special busy loop that waits the modem registration procedure completion to avoid data connection establishing failure. From the 3GPP specification point of view, a UE (modem) has at least three options during the initial network registration procedure: * request the immediate default connection establishing with a specific P-GW (APN) via a long and tricky procedure; * request the immediate default connection establishing without an explicit APN, then MME should use a default one P-GW (APN); * do not establish a data connection immediately. I am, as an occasional user of an LTE modem, never faced a case when the modem is unable to register with a network due to an unconfigured APN. The most prominent fact is that no one else ever faced such case for a 7 years of the uqmi existence. It looks like you either ran into a very special operator, or you have a buggy modem that is recovered via the airplane mode. It is also possible that I do not fully understand your case. I am not against this patch, I am just curious about the described situation with a strict APN requirement. > I have a local uqmi version with commands for checking and modifying > the APN settings. > >>> To make it possible to automate change of APN setting --get-operating-mode >>> is >>> needed. >>> >>> Signed-off-by: Henrik Ginstmark -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Please find a few comments related to a patch submission below. As for the airplane mode requirements, I would like to split that discussion into a separate thread and will send a separate reply. On Sun, Dec 5, 2021 at 2:19 AM Henrik Ginstmark wrote: > Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov : >> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote: >>> This command make it possible to query if the modem is in flight mode or >>> not. >>> >>> If you need to change your APN setting it should be done during flight mode >>> on. >> >> Just curious, is this true for any Qualcomm based mode or only for a >> specific model? > > When an LTE terminal is powered on it needs a valid APN to be able to > register to the > network. Some cellular operators allow an "empty" APN and then set a default > APN > to the terminal. > The most optimal way to power on an LTE terminal would be with flight mode on, > check that the correct APN is configured and then set flight mode off. > This is for all LTE terminals. > > I have a local uqmi version with commands for checking and modifying > the APN settings. > >> >>> To make it possible to automate change of APN setting --get-operating-mode >>> is >>> needed. >>> >>> Signed-off-by: Henrik Ginstmark >> >> Your patch seems broken. Consider using git-format-patch and >> git-send-email to prepare and submit the patch, please. > > Sorry, I´m new to this. Do you know where I can find information about > git-format-patch and git-send-email? You can find more details about these utilities in the corresponding man pages. Please see man git-format-patch and man git-send-email You can find some more information about the patches submitting procedure in the project wiki: * https://openwrt.org/submitting-patches * https://openwrt.org/docs/guide-developer/working-with-git-email Also a good overview of the patch submitting can be found in the Linux kernel documentation: * https://www.kernel.org/doc/html/latest/process/submitting-patches.html A typical workflow for a uqmi patch submission will looks like this: $ git clone https://git.openwrt.org/project/uqmi.git $ cd uqmi $ git checkout -b new-feature-branch hack the code to introduce a new functionality with your favorite code editor $ git commit -s $ git format-patch HEAD^ $ git send-email --to=... --cc=... foo_bar.patch > What I understand is uqmi a sub-project > to openwrt, or? Yep. uqmi is the OpenWrt sub-project. > I´m still learning C. I will try to optimize the code in a better way. Your code looks well. Just needs some polishing :) -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Hello Henrik,
On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote:
> This command make it possible to query if the modem is in flight mode or not.
>
> If you need to change your APN setting it should be done during flight mode
> on.
Just curious, is this true for any Qualcomm based mode or only for a
specific model?
> To make it possible to automate change of APN setting --get-operating-mode is
> needed.
>
> Signed-off-by: Henrik Ginstmark
Your patch seems broken. Consider using git-format-patch and
git-send-email to prepare and submit the patch, please.
BTW, it is a good idea to keep the 'PATCH' word in the subject line,
so patchwork (https://patchwork.ozlabs.org/project/openwrt/list/) will
be able to catch your patch. Something like this:
[PATCH uqmi] dms: add --get-operating-mode
See also a couple of nit picks below.
> commands-dms.c
>
> @@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_m
> return QMI_CMD_REQUEST;
> }
>
> +static void
> +cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
> *req, struct qmi_msg *msg)
> +{
> +struct qmi_dms_get_operating_mode_response res;
> +
This empty line is odd.
> +const char *modes[] = {
You could reuse 'modes' from the cmd_dms_set_operating_mode_prepare()
to avoid duplication. Just move the array out from the function and
call it something like 'oper_modes'.
> +[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
> +[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
> +[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
> +[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
> +[QMI_DMS_OPERATING_MODE_RESET] = "reset",
> +[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
> +[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] =
> "persistent_low_power",
> +[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
> +};
> +int s = 0;
This is a magic number usage. Also if a modem returns unknown value
then the code below will report that the modem is 'online'. What can
be misleading. See the 'get_pin_status()' function for an example of
an unknown value handling.
> +
> +qmi_parse_dms_get_operating_mode_response(msg, &res);
> +if (res.set.mode &&
This part of the check looks odd. If res.set.mode is zero you skip the
's' variable updation, but s is initialized with zero during the
definition.
> +res.data.mode < ARRAY_SIZE(modes))
> +s = res.data.mode;
> +
> +blobmsg_add_string(&status, NULL, modes[s]);
> +}
> +
> +static enum qmi_cmd_result
> +cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
> +{
> +qmi_set_dms_get_operating_mode_request(msg);
> +return QMI_CMD_REQUEST;
> +}
> +
> #define cmd_dms_set_operating_mode_cb no_cb
> static enum qmi_cmd_result
> cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
>
>
> ---
>
> commands-dms.h
>
> @@ -37,6 +37,7 @@
> __uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
> + __uqmi_command(dms_get_operating_mode, get-device-operating-mode,
> no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_operating_mode, set-device-operating-mode,
> required, QMI_SERVICE_DMS), \
> __uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_fcc_authentication, fcc-auth, no, QMI_SERVICE_DMS)
> \
> @@ -67,6 +68,7 @@
> " --get-imei: Get International Mobile
> Equipment ID\n" \
> " --get-msisdn: Get the MSISDN (telephone
> number)\n" \
> " --reset-dms: Reset the DMS service\n" \
> + " --get-device-operating-mode Get the device operating mode\n"
> \
> " --set-device-operating-modeSet the device operating mode\n"
> \
> "(modes: online,
> low_power, factory_test, offline\n" \
> " reset, shutting_down,
> persistent_low_power,\n" \
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
Hello Rosen, On Tue, Nov 30, 2021 at 6:18 AM Rosen Penev wrote: > On Tue, Nov 16, 2021 at 2:14 AM Sergey Ryazanov > wrote: >> Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN >> (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe >> slots with USB and SIM only and another one pure miniPCIe slot as well >> as five Gigabit Ethernet ports (4xLAN + WAN). >> >> Specification: >> >> * SoC: MT7621A >> * RAM: 256/512 MiB >> * Flash: 16/32 MiB (SPI NOR) >> * external watchdog (looks like Torexsemi XC6131B) >> * Eth: 10/100/100 Mbps Ethernet x5 ports (4xLAN + WAN) >> * WLAN 2GHz: MT7603EN (.11n, MIMO 2x2) >> * WLAN 5GHz: MT7612EN (.11ac, MIMO 2x2) >> * WLAN Ants: detachable x2, shared by 2GHz & 5GHz radios >> * miniPCIe: 2x slots with USB&SIM + 1x slot with regular PCIe bus >> * WWAN Ants: detachable x4 >> * External storage: microSD (SDXC) slot >> * USB: 2.0 Type-A port >> * LED: 11 (5 per Eth phy, 3 SoC controlled, 2 WLAN 2/5 controlled, 1 >>power indicator) > switch LEDs can be controlled now. See > https://github.com/openwrt/openwrt/commit/360c181dd747f033cb61f83915ce277c6497720f Nice to hear. It looks like this can help solve some hard special cases with boards that have more puzzled hardware design or for DIY enthusiasts. >> * Button: 1 (reset) >> * UART: console (115200 baud) >> * Power: DC jack (12 V / 2.5 A) -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
On Wed, Nov 24, 2021 at 12:51 AM Sergey Ryazanov wrote: > On Tue, Nov 16, 2021 at 1:09 PM Sergey Ryazanov > wrote: >> Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN >> (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe >> slots with USB and SIM only and another one pure miniPCIe slot as well >> as five Gigabit Ethernet ports (4xLAN + WAN). > > Could the devs invest some time and apply this, please? If anything is > wrong with the patch, please, let me know. Another one friendly ping. Or are all devs busy and I should be more patient? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
On Tue, Nov 16, 2021 at 1:09 PM Sergey Ryazanov wrote: > Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN > (UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe > slots with USB and SIM only and another one pure miniPCIe slot as well > as five Gigabit Ethernet ports (4xLAN + WAN). Could the devs invest some time and apply this, please? If anything is wrong with the patch, please, let me know. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD
On Tue, Nov 16, 2021 at 7:07 PM Denis Kalashnikov wrote:
> On MikroTik RB91x board series a reset key shares SoC gpio
> line #15 with NAND ALE and NAND IO7. So we need a custom
> gpio driver to manage this non-trivial connection schema.
> Also rb91x-nand needs to have ability to disable a polling
> of the key while it works with NAND, and we need to add
> "cansleep" suffix to several gpiolib calls in gpio-latch.
>
> Signed-off-by: Denis Kalashnikov
Please find below one nonsignificant nitpick, in all other respects:
Reviewed-by: Sergey Ryazanov
> +struct gpio_rb91x_key {
> + struct gpio_chip gc;
> + struct mutex mutex;
> + struct mutex poll_mutex;
These mutexes are worth a line of documentation. I do not care too
much, but if by some other reason you will submit v3, please consider
to describe their purpose.
> + int polling_disabled;
> + struct gpio_desc *gpio;
> +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] generic: platform/mikrotik: use MTD notifier
On Tue, Nov 16, 2021 at 7:07 PM Denis Kalashnikov wrote: > If the SPI probe is sufficiently delayed, the routerboot driver may fail > to init as the routerboot partitions are not yet available. > > Register an MTD user notifier instead of doing straight init so that the > init subroutines are only executed when the target MTD partitions are > present. > > Because the init/exit routines can now be called outside of the kernel > normal init/exit calls, they cannot be jettisoned and must always be > available: the __init and __exit qualifiers are thus removed. > > Reported-by: Denis Kalashnikov > Signed-off-by: Denis Kalashnikov > Signed-off-by: Thibaut VARÈNE Denis, Thibaut, nice catch and fix! Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
On Tue, Nov 16, 2021 at 3:40 PM Enrico Mioso wrote: > Does the device use ZLoader? If you mean Zyxel bootloader, then no. The board utilizes U-boot with some PandoraBox patches according to the logo printed to the serial console. > Is a recovery mode available? (maybe document it in the commit) Vendor does not mention any recovery mode in the documentation. You could connect to the serial console and use regular U-boot commandы to recover the firmware. > Does it require LZMA loader for 5.10? Did not test with the 5.10 kernel, but looks like it should run smoothly on the board. What are the specific requirements for LZMA loader usage besides the kernel size limitation? 5.10 is not smaller than 5.4. So, if the 5.4 based firmware requires the LZMA loader to boot with a typical MT7621 U-boot, then 5.10 will require it too. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for Zbtlink ZBT-WG1602
Hello Roger, On Tue, Nov 16, 2021 at 1:29 PM Roger Pueyo Centelles | Guifi.net wrote: > I spotted a very small typo on the commit message: > > * Eth: 10/100/100 Mbps Ethernet x5 ports (4xLAN + WAN) > > is probably > > * Eth: 10/100/1000 Mbps Ethernet x5 ports (4xLAN + WAN) Sure, this should be 1000 Mbps. Thank you for noticing this! Maintainers, should I resend with the fixed message? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: add support for Zbtlink ZBT-WG1602
Zbtlink ZBT-WG1602 is a Wi-Fi router intendent to use with WWAN
(UMTS/LTE/3G/4G) modems. The router board offsers a couple of miniPCIe
slots with USB and SIM only and another one pure miniPCIe slot as well
as five Gigabit Ethernet ports (4xLAN + WAN).
Specification:
* SoC: MT7621A
* RAM: 256/512 MiB
* Flash: 16/32 MiB (SPI NOR)
* external watchdog (looks like Torexsemi XC6131B)
* Eth: 10/100/100 Mbps Ethernet x5 ports (4xLAN + WAN)
* WLAN 2GHz: MT7603EN (.11n, MIMO 2x2)
* WLAN 5GHz: MT7612EN (.11ac, MIMO 2x2)
* WLAN Ants: detachable x2, shared by 2GHz & 5GHz radios
* miniPCIe: 2x slots with USB&SIM + 1x slot with regular PCIe bus
* WWAN Ants: detachable x4
* External storage: microSD (SDXC) slot
* USB: 2.0 Type-A port
* LED: 11 (5 per Eth phy, 3 SoC controlled, 2 WLAN 2/5 controlled, 1
power indicator)
* Button: 1 (reset)
* UART: console (115200 baud)
* Power: DC jack (12 V / 2.5 A)
Additional HW information:
* SoC USB port #1 is shared by internal miniPCIe slot and external
Type-A USB port, USB D+/D- lines are toggled between ports using a
GPIO controlled DPDT switch.
* Power of the USB enabled miniPCIe slots can be individually controlled
using dedicated GPIO lines.
* Vendor firmware feeds the external watchdog with 1s pulses. GPIO
watchdog driver is able to either generate a 1us pulses or toggle the
output line. 1us is not enough for the external watchod timer, so
the line toggling driver mode is utilized.
Installation:
Vendor's firmware is OpenWrt (LEDE) based, so the sysupgrade image can
be directly used to install OpenWrt. Firmware must be upgraded using the
'force' and 'do not save configuration' command line options (or
correspondig web interface checkboxes) since the vendor firmware is from
the pre-DSA era.
Signed-off-by: Sergey Ryazanov
---
.../dts/mt7621_zbtlink_zbt-wg1602-16m.dts | 10 +
.../ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi | 206 ++
target/linux/ramips/image/mt7621.mk | 12 +
3 files changed, 228 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
create mode 100644 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
new file mode 100644
index 00..216c7b3cf0
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602-16m.dts
@@ -0,0 +1,10 @@
+#include "mt7621_zbtlink_zbt-wg1602.dtsi"
+
+/ {
+ compatible = "zbtlink,zbt-wg1602-16m", "zbtlink,zbt-wg1602",
"mediatek,mt7621-soc";
+ model = "Zbtlink ZBT-WG1602 (16M)";
+};
+
+&firmware {
+ reg = <0x5 0xfb>;
+};
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
new file mode 100644
index 00..e377a13444
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg1602.dtsi
@@ -0,0 +1,206 @@
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "zbtlink,zbt-wg1602", "mediatek,mt7621-soc";
+
+ aliases {
+ led-boot = &led_sm;
+ led-failsafe = &led_sm;
+ led-running = &led_sm;
+ led-upgrade = &led_sm;
+ label-mac-device = &gmac0;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_sm: sm {
+ label = "green:sm";
+ gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ 4g1 {
+ label = "green:4g1";
+ gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ 4g2 {
+ label = "green:4g2";
+ gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ watchdog {
+ compatible = "linux,wdt-gpio";
+ gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
+ hw_algo = "toggle";
+ /* hw_margin_ms is actually ~120s but driver limits it to 60s */
+ hw_margin_ms = <6>;
+ always-running;
+ };
+
+ gpio-export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ 4g1-pwr {
+ gpio-export,name = "4g1-pwr";
+
Re: uml: drop target
Hello Bastian, On Thu, Oct 14, 2021 at 9:11 PM Bastian Bittorf wrote: > I'am also an infrequent user. I do not see an issue > for the moment, it compiles and runs just fine: Thank you for taking care of testing it, one less problem. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On Mon, Oct 11, 2021 at 12:12 AM Hauke Mehrtens wrote: > On 10/10/21 2:44 AM, Sergey Ryazanov wrote: >> On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra wrote: >>> On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: >>>> Nothing in this target has more than 32 MiB of RAM (most devices have >>>> 16 MiB) [1]. Just put it out of its misery. :) >>> >>> Scratch that. After chatting with dangole, there may be some life in >>> it, after all. I have an ath25 device (FON2200) and didn't even >>> remember it. >> >> I am in the process of migrating ath25 to the 5.10 kernel. Initial >> build was trivial. But I need to restore the Marvel swconfig driver >> that was lost during the initial 5.10 kernel introduction, and >> carefully run-time test it. > > Does it make sense to directly convert this board to the upstream DSA > driver for the Marvell 88E6060 switch: > https://elixir.bootlin.com/linux/v5.10.72/source/drivers/net/dsa/mv88e6060.c > It looks like our swconfig driver creates a bridge over all ports and > the DSA driver only allows communication between the individual port and > the CPU port. > > I do not know how much effort this is and if you have the device for > testing. I do not think that migration to DSA without DT support will be a practical step. Let's keep it as is until we are able to run new kernels with it. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hello Rui, On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra wrote: > On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: >> Nothing in this target has more than 32 MiB of RAM (most devices have >> 16 MiB) [1]. Just put it out of its misery. :) > > Scratch that. After chatting with dangole, there may be some life in > it, after all. I have an ath25 device (FON2200) and didn't even > remember it. I am in the process of migrating ath25 to the 5.10 kernel. Initial build was trivial. But I need to restore the Marvel swconfig driver that was lost during the initial 5.10 kernel introduction, and carefully run-time test it. I bricked (or possibly broke) my test FON2200 during the last migration to the 5.4. Would you like to volunteer and test the new version as soon as it will be ready? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uml: drop target
On Fri, Oct 8, 2021 at 10:17 PM Paul Spooren wrote: > On 10/8/21 5:54 AM, Sergey Ryazanov wrote: >> On Fri, Oct 8, 2021 at 12:05 PM Paul Spooren wrote: >>> as previously posted on GitHub[1] I'd like to remove the UML target >>> since it seems broken, isn't offered by our buildbots and it's purpose >>> for testing can be replaced by using qemu. >>> >>> Is anyone here actively using UML and would like to keep it? >>> >>> [1]: https://github.com/openwrt/openwrt/pull/4643 >> I personally do not use UML yet. I tested it a few months ago, It >> works smoothly and I find it a good lightweight solution for testing >> of massive installations like a routing protocol evaluation or a load >> testing, etc. >> >> What are the drawbacks of keeping UML? > > I tried to compile it the other day and the Kernel wouldn't compile. > Since we want Kernel 5.10 only for the next release UML needs a > (working) bump to 5.10 or will be dropped. > > Could you have a look at it? Yep, I will check it as soon as I finish ath25 migration. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uml: drop target
Hello Paul, thank you for posting this to ML. On Fri, Oct 8, 2021 at 12:05 PM Paul Spooren wrote: > as previously posted on GitHub[1] I'd like to remove the UML target > since it seems broken, isn't offered by our buildbots and it's purpose > for testing can be replaced by using qemu. > > Is anyone here actively using UML and would like to keep it? > > [1]: https://github.com/openwrt/openwrt/pull/4643 I personally do not use UML yet. I tested it a few months ago, It works smoothly and I find it a good lightweight solution for testing of massive installations like a routing protocol evaluation or a load testing, etc. What are the drawbacks of keeping UML? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: kernel: Add missing quote to drivers/mfd/Kconfig
On Thu, Jul 22, 2021 at 1:34 AM Paul Blazejowski wrote: > A missing quote in target/linux/ath79/patches-5.x/920-mikrotik-rb4xx.patch > produces: > > ... > scripts/kconfig/conf --syncconfig Kconfig > drivers/mfd/Kconfig:2016:warning: multi-line strings not supported > ... > > This patch adds missing closing quote, fixing the above warning. > > Signed-off-by: Paul Blazejowski Nice catch! Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] comgt: Move to community packages repo
Hello Petr, On Fri, Jul 2, 2021 at 12:31 PM Petr Štetiar wrote: > Sergey Ryazanov [2021-06-29 02:07:16]: >> OTOH, Arjun has been trying to draw attention to the patch for comgt >> for a year. And no one reacted to his quite reasonable fix. > > As always, any additional `Tested-by` or `Reviewed-by` helps. Yep, it is my fault too :( I thought that this fix is so trivial, but missed the fact that maintainers need feedback from the community too. That was discussed many times, but it is much easier to blame maintainers for not applying fixes, than help with the review :) Let's hope I learned a thing or two from this case. > Anyway, I've merged it already. Thank you! -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] comgt: Move to community packages repo
On Mon, Jun 28, 2021 at 11:57 PM Lech Perczak wrote: > W dniu 2021-06-28 o 21:55, Paul Spooren pisze: >> On 6/28/21 9:53 AM, John Crispin wrote: >>> On 28.06.21 21:14, Paul Spooren wrote: I'm in favor of this too but if it's a core feature (i.e. SIM card support) we should provide the package by default to, not? >>> >>> this should be explained in the wiki, >> >> Agree, APU boards etc also need some extra packages to support SDcards >> and things. Let's do this. > > OTOH, this differs a bit from such packages, by being needed to connect > to WAN on such devices. This is the same way as uqmi does on some - > removing it would require other Internet connection to bootstrap its > installation. Yep, removing the comgt package from the firmware sounds like an anecdote from the 90's: The modem driver is on CD, the CD-ROM driver on the Internet. OTOH, Arjun has been trying to draw attention to the patch for comgt for a year. And no one reacted to his quite reasonable fix. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/1] Reset modem upon initialization.
Hello Ontje,
On Mon, Jun 28, 2021 at 3:00 PM wrote:
> The rut955 fails to activate its modem upon every second reboot otherwise.
What does it mean "fails to activate modem"? Could you be more
specific? A bit more detailed issue description will be helpful if
someone faces a similar case, even possibly with another modem model.
Whether the modem does not respond at all or it is unable to establish
a new data connection? Did you try to purge the modem clients list and
then reestablish the connection?
> Co-authored-by: hans-hermann.reden...@dlr.de
> Co-authored-by: jonas.stuehrenb...@dlr.de
BTW, you missed the Signed-of-by :)
> ---
> package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index c0134f4..60695ec 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -81,6 +81,10 @@ proto_qmi_setup() {
>
> echo "Waiting for SIM initialization"
> local uninitialized_timeout=0
> +
> + # Reset modem, workaround for a buggy modem after an reboot
> + uqmi -s -d "$device" --set-device-operating-mode reset
> +
As already mentioned by Piotr, resetting the modem on each connection
establishing attempt is overkill. Did you consider using a hotplug
script to reset the modem after the initial detection?
With a hotplug script you even will be able to reset only a specific
buggy modem model and reduce side-effects.
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] ath79: add gpio-latch driver for MikroTik RouterBOARDs
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > This is a slighty modified version of ar71xx gpio-latch driver > written by Gabor Juhos . > > Changes: > * DTS support, > * New gpio API (gpiod_*). > > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] ath79: add NAND driver for MikroTik RB91xG series
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > Main part is copied from ar71xx original driver rb91x_nand > written by Gabor Juhos . > > What is done: > * Support of kernel 5.4 and 5.10, > * DTS support, > * New gpio API (gpiod_*) support. > > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Mon, Jun 14, 2021 at 6:29 PM Koen Vandeputte wrote: > On 27.05.21 10:16, Denis Kalashnikov wrote: > > From: Denis Kalashnikov > > > > RB912 needs two ad hoc drivers: gpio-latch and rb91x_nand. So I've ported > > them > > from ar71xx and added DTS. > > > > In RFC v1 I added a MFD driver that provided API for manipulating shared > > gpio > > lines to gpio-latch and nand drivers. In RFC v2 I just ported gpio-latch and > > rb91x_nand drivers from ar71xx to ath79 by adding DTS support and usage of > > a new gpio API (gpiod_*). This way is turned to be more clear and compact. > > So, I've tried to fix what you guys advised me and here is my patches v1. > > > > All seems to be working on my RB912UAG-2HPnD. Except a button and a beeper. > > The > > beeper seems is not important thing, but the button is. The button shares > > gpio > > 15 with NAND ALE and NAND IO7, but this is not easily supported by the > > current > > drivers. May be we need ad hoc driver for button. Or may be there is a more > > general solution for this problem (like rb91x-gpio driver that arbitrates > > all gpio lines instead of gpio-latch). This can be fixed in the next > > patches. > > > > Denis Kalashnikov (3): > >ath79: add gpio-latch driver for MikroTik RouterBOARDs > >ath79: add NAND driver for MikroTik RB91xG series > >ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD > > > > ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++ > > .../ath79/files/drivers/gpio/gpio-latch.c | 203 ++ > > .../files/drivers/mtd/nand/raw/rb91x_nand.c | 375 ++ > > target/linux/ath79/image/mikrotik.mk | 9 + > > .../base-files/etc/board.d/02_network | 2 + > > .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + > > .../base-files/lib/upgrade/platform.sh| 1 + > > target/linux/ath79/mikrotik/config-default| 1 + > > .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ > > .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ > > 10 files changed, 899 insertions(+) > > create mode 100644 > > target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts > > create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c > > create mode 100644 > > target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c > > create mode 100644 > > target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch > > create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch > > > Tested on the 5GHz flavor and works fine > > > Any other objections/remarks? Still have no chance to run-test it, but the code looks overly good for me. > I will merge this otherwise tomorrow. Thanks for taking care of this. Just curious. Are there any chances that support for this board will be backported to the 21.02 branch? -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Thu, May 27, 2021 at 11:18 AM Denis Kalashnikov wrote: > From: Denis Kalashnikov > > This board has been supported in the ar71xx. > > Links: > * https://mikrotik.com/product/RB912UAG-2HPnD > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd > > Hardware: > * SoC: Atheros AR9342, > * RAM: DDR 64MB, > * SPI NOR: 64KB, > * NAND: 128MB, > * Ethernet: x1 10/100/1000 port with passive POE in, > * Wi-Fi: 802.11 b/g/n, > * PCIe, > * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A > port -- both can be used for LTE modem. But only one can be used. > * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED, > Ethernet phy LED, > * Button, > * Beeper. > > Not working: > * Button: it shares gpio line 15 with NAND ALE and NAND IO7, > and current drivers doesn't easily support this configuration, > * Beeper: it is connected to bit 5 of a serial shift register > (tested with sysfs led trigger timer). But kmod-gpio-beeper > doesn't work -- we left this as is for now. > > Flashing: > * Use the RouterBOARD Reset button to enable TFTP netboot, > boot kernel and initramfs and then perform sysupgrade. > * From ar71xx OpenWrt firmware run: > $ sysupgrade -F /tmp/ > For more info see: https://openwrt.org/toh/mikrotik/common. > > Co-Developed-by: Koen Vandeputte > Signed-off-by: Denis Kalashnikov Reviewed-by: Sergey Ryazanov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On Mon, Jun 14, 2021 at 9:02 PM Adrian Schmutzler
wrote:
>
> Hi,
>
> a few remaining comments below.
>
>> + gpio-export {
>> + compatible = "gpio-export";
>> +
>> + usb_power {
>> + label = "power:usb";
>
> gpio-export nodes normally don't have a label property. We have
> gpio-export,name instead.
>
>> + gpio-export,name = "power-usb";
>> + gpio-export,output = <1>;
>> + gpios = <&ssr 6 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + pcie_power {
>> + label = "power:pcie";
>> + gpio-export,name = "power-pcie";
>> + gpio-export,output = <0>;
>> + gpios = <&ssr 7 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&spi {
>> + status = "okay";
>> +
>> + compatible = "qca,ar7100-spi";
>> +
>> + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>;
>
> I still don't think this belongs here. Why would it be the only device
> requiring this, while we removed it everywhere else?
Every other board uses SPI controller CS lines, so they are not needed
in this property. While the RB912 board uses the controller CS line
only to control the first device on the bus, and the regular GPIO line
to control the second device. So yes, this board requires the cs-gpios
property.
This board is overly special, the latch based GPIO controller will
just suffice to mention.
>> +
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <8000>;
>
> Typically, speeds > 50 MHz require m25p,fast-read?
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ath79: rb4xx-nand: fix 512 byte pages compatibility
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old OOB
layout from being used.
To fix this issue, move the page size check and OOB layout configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
Changes since v1:
* rebased on top of latest master
* rephrased the comment in the hook function, thanks to Bas for
noticing this
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 22e2660b38..6778e70d34 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* At this point, we know the flash params and can tweak the OOB layout
+* for 512-byte page (usually this is a 64MiB flash).
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip *chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
-
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,9,0)
nand->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
nand->chip.ecc.algo = NAND_ECC_ALGO_HAMMING;
@@ -204,6 +222,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = &rb4xx_nand_controller_ops;
ret = nand_scan(&nand->chip, 1);
if (ret)
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hello Adrian,
On Mon, May 31, 2021 at 1:15 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sergey Ryazanov
> > Sent: Montag, 24. Mai 2021 01:07
> > To: Adrian Schmutzler ; Denis Kalashnikov
> >
> > Cc: OpenWrt Development List ; Gabor
> > Juhos ; Koen Vandeputte
> >
> > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
> >
> > Hello Adrian and Denis,
> >
> > sorry for interfering with your conversation, I would like to discuss the
> > best
> > way to document not yet finished functionality. Please find my question and
> > proposal below.
> >
> > On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler
> > wrote:
> >
> > [skipped]
> >
> > >> + beeper {
> > >> + status = "disabled";
> > >> + compatible = "gpio-beeper";
> > >> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>;
> > >> + };
> > >
> > > If it's broken, I'd not add it here but just name the correct GPIO number
> > > in
> > the commit message.
> > >
> > >> +
> > >> + keys {
> > >> + status = "disabled";
> > >
> > > Like above: If it's broken, remove it, so nobody enables it accidentally
> > > and
> > causes harm.
> > > (But document how to set it up in the commit message, as you mostly
> > > did already ...)
> >
> > Factoring out realization details to the commit message is quite unusual, I
> > personally assume that the commit message is a place where a committer
> > should describe reasons for a particular change. While hard to understand
> > things should be commented on in the code themself.
> >
> > I agree with Adrian that a not yet finished code should not be committed to
> > the master branch. But the device tree has a dualistic nature, on one hand
> > it
> > is a place for driver configuration, on the other hand it is a way to
> > document
> > board stuff interconnections. So maybe we should combine Denise's
> > approach to document even a not yet fully supported component in the DTS
> > with Adrian's suggestion to document why a component is not supported yet
> > and place the reason to disable DTS node as comment inside the node? E.g.:
>
> My main motivation is preventing too much bloat in the DTS files.
>
> Nevertheless, typically, if stuff is not working it will either not be
> resolved ever
> or the solution will deviate from what people were thinking it would be
> initially
> (otherwise, they would have solved it back then). Thus, the DTS
> "implementation" of that part is either irrelevant (first case) or
> wrong/subject
> to change (second case) later. In both cases, I don't think it really makes
> sense to add it to the DTS in the first place.
Well! These reasons for not adding broken nodes to DTS sounds
perfectly reasonable for me.
But what is the best way to document hard-to-find but not yet
functional GPIO lines then? Wiki? If so, should we add a wiki page URL
as a comment to the DTS to facilitate work of future contributors?
> Hovewer, I'm relatively flexible here. So if you really think it would be
> necessary to have this broken part of configuration in the DTS, I won't stop
> you because of that.
>
> >
> > 8< --- keys {
> > compatible = "gpio-keys-polled";
> >
> > reset {
> > ...
> > gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> > /*
> > * GPIO line #15 is shared between the reset button on input and
> > * the NAND ALE (via the latch) on output. We are unable to just
> > * enable the reset button. So, this node here is for
> > * documentation purposes only.
> > *
> > * [Here should be a text describing the possible ways to
> > * overcome shared line issues]
> > */
> > status = "disabled";
> > };
> > };
> > 8< ---
> >
> > This way we will keep all interconnection documentation in DTS and at the
> > same time we will make sure that no sane user enables this node.
> >
> > > > + compatible = "gpio-keys";
> > > > + reset {
> > > > + label = "reset";
> > > > + linux,code = ;
> > > > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> > > > + debounce-interval = <60>;
> > > > + };
> > > > + };
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
Hello Bas,
thank you for your review, please find my comments below.
On Fri, May 28, 2021 at 11:41 AM Bas Mevissen wrote:
> On 2021-05-28 00:27, Sergey Ryazanov wrote:
[skipped]
>> +static int rb4xx_nand_attach_chip(struct nand_chip *chip)
>> +{
>> + struct mtd_info *mtd = nand_to_mtd(chip);
>> +
>> + /*
>> + * Now we knows flash parameters and can tweak OOB the layout for old
>
> Rephrase to something like:
> Knowing the flash parameters, we can tweak the OOB layout for old
>
Yeah, I am not happy with this comment too, but this is the best I was
able to compose at 01:00 :) I will rephrase it if V2 will be needed.
Here we need a comment that briefly and clearly states that the NAND
params become known at this particular moment of initialization.
Before this moment, we do not know the page size, after this moment it
is too late to reconfigure something. Do you have any thoughts?
>> + * (usually 64MiB) flashes.
>> + *
>> + * We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
>> + * bootloader will not be able to find the kernel that we load.
>> + */
>> + if (mtd->writesize == 512)
>> + mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
>> +
>> + return 0;
>> +}
>> +
>> static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
>> {
>> struct rb4xx_nand *nand = chip->priv;
>> @@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
>> *chip)
>> return gpiod_get_value_cansleep(nand->rdy);
>> }
>>
>> +static const struct nand_controller_ops rb4xx_nand_controller_ops = {
>> + .attach_chip = rb4xx_nand_attach_chip,
>
> remove the ,
I intentionally placed the comma here to make text git-friendly. If we
will need to define more callbacks here, then we will just add a new
new line, without modifying the earlier added lines.
E.g. if commit this code without the comma, then a chip detaching
callback patch will looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
- .attach_chip = rb4xx_nand_attach_chip
+ .attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
With this intentionally placed comma, the same theoretical patch will
looks like this:
static const struct nand_controller_ops rb4xx_nand_controller_ops = {
.attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
};
So this comma is my investment in the future ;)
>> +};
>> +
>> static int rb4xx_nand_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device
>> *pdev)
>> mtd->dev.parent = dev;
>> mtd_set_of_node(mtd, dev->of_node);
>>
>> - if (mtd->writesize == 512)
>> - mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
>> -
>> nand->chip.ecc.mode = NAND_ECC_SOFT;
>> nand->chip.ecc.algo = NAND_ECC_HAMMING;
>> nand->chip.options = NAND_NO_SUBPAGE_WRITE;
>> @@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device
>> *pdev)
>> nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
>> nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
>> nand->chip.legacy.chip_delay= 25;
>> + nand->chip.legacy.dummy_controller.ops = &rb4xx_nand_controller_ops;
>
> Fix indentation for all nand->something assignments to line up the =
> sign
I do not think that this is a good idea for this patch. Here we add
one line that configures the single field deep inside the structure.
The line is placed after the configuration of "surface" fields. So the
overall look should not be harmed dreadfully.
In case we will rework the indentation with this patch, the 57 lines
patch will become a ~70 lines patch. Where at least 12 lines will
rework indentation, so the functional part could be easily lost. Also
the moving text back and forth within an item line, turns the history
to the white noise and makes git-blame(1) usage a pain.
If you prefer, then I could insert an empty line before the ops setup
to make it nice looking. E.g. turn this hunk:
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = &rb4xx_nand_controller_ops;
into this:
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chi
[PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility
MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old OOB
layout from being used.
To fix this issue, move the page size check and OOB layout configuration
to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.
While at it, copy a comment from the old AR71xx driver to make it clear,
why do we need this OOB layout tweaking.
Run tested with MikroTik RB411U board.
Signed-off-by: Sergey Ryazanov
---
.../files/drivers/mtd/nand/raw/nand_rb4xx.c | 25 ---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 50bd69f6a4..00c65d14ae 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
};
+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+* Now we knows flash parameters and can tweak OOB the layout for old
+* (usually 64MiB) flashes.
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
+
+ return 0;
+}
+
static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
{
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip *chip)
return gpiod_get_value_cansleep(nand->rdy);
}
+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+ .attach_chip = rb4xx_nand_attach_chip,
+};
+
static int rb4xx_nand_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
mtd->dev.parent = dev;
mtd_set_of_node(mtd, dev->of_node);
- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, &rb4xx_nand_ecclayout_ops);
-
nand->chip.ecc.mode = NAND_ECC_SOFT;
nand->chip.ecc.algo = NAND_ECC_HAMMING;
nand->chip.options = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device *pdev)
nand->chip.legacy.cmd_ctrl = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = &rb4xx_nand_controller_ops;
ret = nand_scan(&nand->chip, 1);
if (ret)
--
2.26.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 2/3] ath79: add NAND driver for Mikrotik RB91xG series
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov wrote:
> Main part is copied from ar71xx original driver rb91x_nand
> written by Gabor Juhos .
>
> What is done:
> * Support of kernel 5.4 and 5.10,
> * DTS support,
> * New gpio API (gpiod_*) support.
>
> Signed-off-by: Denis Kalashnikov
> ---
>
> Changelog:
>
> v1-->v2:
> - Do not use MFD driver API anymore.
>
> ---
> .../files/drivers/mtd/nand/raw/rb91x_nand.c | 414 ++
> target/linux/ath79/mikrotik/config-default| 1 +
> .../patches-5.10/939-mikrotik-rb91x.patch | 24 +
> .../patches-5.4/939-mikrotik-rb91x.patch | 21 +
> 4 files changed, 460 insertions(+)
> create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
>
> diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
> b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
> new file mode 100644
> index 00..069c2978f7
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
> @@ -0,0 +1,414 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * NAND flash driver for the MikroTik RouterBOARD 91x series
> + *
> + * Main part is copied from original driver written by Gabor Juhos.
> + *
> + * Copyright (C) 2013-2014 Gabor Juhos
> + */
> +
> +/*
> + * WARNING: to speed up NAND reading/writing we are working with SoC GPIO
> + * controller registers directly -- not through standard GPIO API.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* TODO: ar71xx regs (SoC GPIO controller ones) should be get from DTS? */
> +#include
> +
> +#define RB91X_NAND_DRIVER_NAME "rb91x-nand"
It is used only in one place for driver structure filling. So the
special macro is not really required.
> +static void __iomem *ath79_gpio_base;
Should this global variable be placed in the main driver state container?
> +#define RB91X_NAND_DRIVER_DESC "MikrotTik RB91x NAND flash driver"
You do not need this macro. Besides the odd trace message in the probe
function, it is only used to fill the kernel module metadata.
> +/* Bit masks for NAND data lines in ath79 gpio 32-bit register */
> +#define RB91X_NAND_NRW_BIT BIT(12)
> +#define RB91X_NAND_DATA_BITS (BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(4) \
> + | BIT(13) | BIT(14) | BIT(15))
> +#define RB91X_NAND_LOW_DATA_MASK 0x1f
> +#define RB91X_NAND_HIGH_DATA_MASK 0xe0
> +#define RB91X_NAND_HIGH_DATA_SHIFT 8
> +
> +enum rb91x_nand_gpios {
> + RB91X_NAND_ALE, /* Address Latch Enable */
> + RB91X_NAND_CLE, /* Command Latch Enable */
> + RB91X_NAND_NCE, /* Chip Enable. Active low */
> + RB91X_NAND_NRW, /* Read/Write. Active low */
> + RB91X_NAND_READ,/* Read */
> + RB91X_NAND_RDY, /* NAND Ready */
> + RB91X_NAND_NLE, /* Latch Enable. Active low */
> +
> + RB91X_NAND_GPIOS,
> +};
> +
> +struct rb91x_nand_drvdata {
> + struct nand_chip chip;
> + struct device *dev;
> + struct gpio_desc *gpio[RB91X_NAND_GPIOS];
> +};
> +
> +static void rb91x_nand_latch_lock(struct rb91x_nand_drvdata *drvdata, int
> lock)
> +{
> + gpiod_set_value_cansleep(drvdata->gpio[RB91X_NAND_NLE], lock);
> +}
> +
> +static struct mtd_info *rb91x_nand_drvdata_to_mtd(struct rb91x_nand_drvdata
> *drvdata)
> +{
> + return nand_to_mtd(&drvdata->chip);
> +}
> +
> +static int rb91x_ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + switch (section) {
> + case 0:
> + oobregion->offset = 8;
> + oobregion->length = 3;
> + return 0;
> + case 1:
> + oobregion->offset = 13;
> + oobregion->length = 3;
> + return 0;
> + default:
> + return -ERANGE;
> + }
> +}
> +
> +static int rb91x_ooblayout_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + switch (section) {
> + case 0:
> + oobregion->offset = 0;
> + oobregion->length = 4;
> + return 0;
> + case 1:
> + oobregion->offset = 4;
> + oobregion->length = 1;
> + return 0;
> + case 2:
> + oobregion->offset = 6;
> + oobregion->length = 2;
> + return 0;
> + case 3:
> + oobregion->offset = 11;
> + oobregion->length = 2;
> + return 0;
> + default:
> + return -ERANGE;
> + }
> +}
> +
> +static const struct mtd_ooblayout_ops rb91x_nand_ecclayout_ops = {
> + .ecc = rb91x_ooblayout_ecc,
> + .free = rb91x_ooblayout_free,
> +};
> +
> +/* TODO: Should be in DTS */
> +static struct mtd_partition rb91x_nand_partitions[] = {
Looks like you could drop this array, since flash
Re: [RFC v2 1/3] ath79: add gpio-latch driver for Mikrotik RouterBoards
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov wrote:
> This is a slighty modified version of ar71xx gpio-latch driver
> written by Gabor Juhos .
>
> Changes:
> * DTS support,
> * New gpio API (gpiod_*).
>
> Signed-off-by: Denis Kalashnikov
> ---
>
> Changelog:
>
> v1-->v2:
> - Don't use MFD driver API anymore.
>
> ---
> .../ath79/files/drivers/gpio/gpio-latch.c | 225 ++
> .../patches-5.10/939-mikrotik-rb91x.patch | 25 ++
> .../patches-5.4/939-mikrotik-rb91x.patch | 23 ++
> 3 files changed, 273 insertions(+)
> create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c
> create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch
> create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch
>
> diff --git a/target/linux/ath79/files/drivers/gpio/gpio-latch.c
> b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
> new file mode 100644
> index 00..cb80b29052
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/gpio/gpio-latch.c
> @@ -0,0 +1,225 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * GPIO latch driver
> + *
> + * Copyright (C) 2014 Gabor Juhos
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GPIO_LATCH_DRIVER_NAME "gpio-latch"
> +#define GPIO_LATCH_LINES 9
> +
> +struct gpio_latch_chip {
> + struct gpio_chip gc;
> + struct mutex mutex;
> + struct mutex latch_mutex;
> + bool latch_enabled;
> + int le_gpio;
> + bool le_active_low;
> + struct gpio_desc **gpios;
> +};
> +
> +static inline struct gpio_latch_chip *to_gpio_latch_chip(struct gpio_chip
> *gc)
> +{
> + return container_of(gc, struct gpio_latch_chip, gc);
> +}
> +
> +static void gpio_latch_lock(struct gpio_latch_chip *glc, bool enable)
> +{
> + mutex_lock(&glc->mutex);
> +
> + if (enable)
> + glc->latch_enabled = true;
> +
> + if (glc->latch_enabled)
> + mutex_lock(&glc->latch_mutex);
> +}
> +
> +static void gpio_latch_unlock(struct gpio_latch_chip *glc, bool disable)
> +{
> + if (glc->latch_enabled)
> + mutex_unlock(&glc->latch_mutex);
> +
> + if (disable)
> + glc->latch_enabled = true;
> +
> + mutex_unlock(&glc->mutex);
> +}
> +
> +static int
> +gpio_latch_get(struct gpio_chip *gc, unsigned offset)
> +{
> + struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
> + int ret;
> +
> + gpio_latch_lock(glc, false);
> + ret = gpiod_get_value(glc->gpios[offset]);
> + gpio_latch_unlock(glc, false);
> +
> + return ret;
> +}
> +
> +static void
> +gpio_latch_set(struct gpio_chip *gc, unsigned offset, int value)
> +{
> + struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
> + bool enable_latch = false;
> + bool disable_latch = false;
> +
> + if (offset == glc->le_gpio) {
> + enable_latch = value ^ glc->le_active_low;
> + disable_latch = !enable_latch;
> + }
> +
> + gpio_latch_lock(glc, enable_latch);
> + gpiod_set_value(glc->gpios[offset], value);
> + gpio_latch_unlock(glc, disable_latch);
> +}
> +
> +static int
> +gpio_latch_direction_input(struct gpio_chip *gc, unsigned offset)
Latch is the output-only GPIO controller, so why do you need this callback?
> +{
> + struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
> + int ret;
> +
> + gpio_latch_lock(glc, false);
> + ret = gpiod_direction_input(glc->gpios[offset]);
> + gpio_latch_unlock(glc, false);
> +
> + return ret;
> +}
> +
> +static int
> +gpio_latch_direction_output(struct gpio_chip *gc, unsigned offset, int value)
> +{
> + struct gpio_latch_chip *glc = to_gpio_latch_chip(gc);
> + bool enable_latch = false;
> + bool disable_latch = false;
> + int ret;
> +
> + if (offset == glc->le_gpio) {
> + enable_latch = value ^ glc->le_active_low;
> + disable_latch = !enable_latch;
> + }
> +
> + gpio_latch_lock(glc, enable_latch);
> + ret = gpiod_direction_output(glc->gpios[offset], value);
> + gpio_latch_unlock(glc, disable_latch);
> +
> + return ret;
> +}
> +
> +static int gpio_latch_probe(struct platform_device *pdev)
> +{
> + struct gpio_latch_chip *glc;
> + struct gpio_chip *gc;
> + struct device *dev = &pdev->dev;
> + struct device_node *of_node = dev->of_node;
> + struct gpio_descs *gpios;
> + int i;
> + enum of_gpio_flags flags;
> +
> + glc = devm_kzalloc(dev, sizeof(*glc), GFP_KERNEL);
> + if (!glc)
> + return -ENOMEM;
> +
> + mutex_init(&glc->mutex);
> + mutex_init(&glc->latch_mutex);
> +
> + gpios = devm_gpiod_get_array(dev, NULL, 0);
> + if (IS_ERR(gpios)) {
> + dev_err(dev, "failed to get gpios: %d\n", (int)gpios)
Re: [RFC 0/3] ath79: add support for Mikrotik RouterBoard 912G
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov wrote: > In the first vertion of these patches I've added a MFD driver that > provides API for manipulating shared gpio lines to gpio-latch and nand > drivers. Now I just port gpio-latch and rb91x_nand drivers from ar71xx > to ath79 by adding DTS support and new gpio API (gpiod_*). This way turned > to be more clear and compact. All is working on my RB912UAG-2HPnD. Except a > button and a beeper. The beeper seems is not important thing, but the > button is. The button shares gpio 15 with NAND ALE and NAND IO7, but this > is not easily supported by the current drivers. May be we need ad hoc driver > for button. Or may be there is a more general solution for this problem. > Nevertheless all other seems to be working. > > Denis Kalashnikov (3): > ath79: add gpio-latch driver for Mikrotik RouterBoards > ath79: add NAND driver for Mikrotik RB91xG series > ath79: add support for Mikrotik RouterBoard 912G > > .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++ > .../ath79/files/drivers/gpio/gpio-latch.c | 225 ++ > .../files/drivers/mtd/nand/raw/rb91x_nand.c | 414 ++ > target/linux/ath79/image/mikrotik.mk | 9 + > .../base-files/etc/board.d/02_network | 2 + > .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + > .../base-files/lib/upgrade/platform.sh| 1 + > target/linux/ath79/mikrotik/config-default| 1 + > .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ > .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ > 10 files changed, 979 insertions(+) > create mode 100644 > target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c > create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c > create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch > create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch Thank you for this update, please find a few comments per-patch. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov wrote:
>
> This board has been supported in the ar71xx.
>
> Links:
> * https://mikrotik.com/product/RB912UAG-2HPnD
> * https://mikrotik.com/product/RB912UAG-5HPnD
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd
>
> Hardware:
> * SoC: Atheros AR9342,
> * RAM: DDR 64MB,
> * SPI NOR: 64KB,
> * NAND: 128MB,
> * Ethernet: x1 10/100/1000 port with passive POE in,
> * Wi-Fi: 802.11bgn,
> * PCIe,
> * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A
> port -- both can be used for LTE modem. But only one can be used.
> * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED,
> Ethernet phy LED,
> * Button,
> * Beeper.
>
> Not working:
> * Button: it shares gpio line 15 with NAND ALE and NAND IO7,
> and current drivers doesn't easily support this configuration,
> * Beeper: it is connected to bit 5 of a serial shift register
> (tested with sysfs led trigger timer). But kmod-gpio-beeper
> doesn't work -- we left this as is for now.
>
> You can flash image by sysupgrade utility or load it by net
> (by DHCP/TFTP, hold the button while booting).
>
> Co-Developed-by: Koen Vandeputte
> Signed-off-by: Denis Kalashnikov
> ---
>
> Changelog:
>
> v1->v2:
> - Delete uneeded comments from DTS,
> - Delete ascii-art of board scheme near NAND latch from DTS,
> - Rewrite gpio_latch and nand_gpio nodes to be consistent with the
> new versions of drivers,
> - Fix SPI NOR flash and SPI serial shift register maximum speeds
> (thanks to Koen Vandeputte),
> - Add UART, PCIe, USB support and gpio exports (thanks to Koen Vandeputte),
> - Fix Ethernet node (thanks to Koen Vandeputte),
> - Add key and beeper nodes in disabled state just to be documented.
>
> ---
> .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++
> target/linux/ath79/image/mikrotik.mk | 9 +
> .../base-files/etc/board.d/02_network | 2 +
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
> .../base-files/lib/upgrade/platform.sh| 1 +
> 5 files changed, 246 insertions(+)
> create mode 100644
> target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> new file mode 100644
> index 00..a23fc04a99
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "ar9344.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g", "qca,ar9342";
> + model = "Mikrotik RouterBoard 912G";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power {
> + label = "green:power";
> + gpios = <&gpio_latch 1 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + led_user {
> + label = "green:user";
> + gpios = <&gpio_latch 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led1 {
> + label = "green:led1";
> + gpios = <&ssr 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led2 {
> + label = "green:led2";
> + gpios = <&ssr 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led3 {
> + label = "green:led3";
> + gpios = <&ssr 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led4 {
> + label = "green:led4";
> + gpios = <&ssr 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led5 {
> + label = "green:led5";
> + gpios = <&ssr 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + beeper {
> + status = "disabled";
> + compatible = "gpio-beeper";
> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + keys {
> + status = "disabled";
> + compatible = "gpio-keys";
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> + debounce-interval = <60>;
> + };
> + };
> +
> + gpio_export {
> + compatible = "gpio-export";
> +
> + usb_select {
> + label = "select:usb";
> + gpio-export,name = "mikrotik:select:usb";
> + gpio-export,output = <0>; /* 0: mini-pcie, 1: Type-A
> port */
> + gpios = <&ssr 6 GPIO_ACTIVE_LOW>;
> + };
> +
> +
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hello Adrian and Denis,
sorry for interfering with your conversation, I would like to discuss
the best way to document not yet finished functionality. Please find
my question and proposal below.
On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler
wrote:
[skipped]
>> + beeper {
>> + status = "disabled";
>> + compatible = "gpio-beeper";
>> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>;
>> + };
>
> If it's broken, I'd not add it here but just name the correct GPIO number in
> the commit message.
>
>> +
>> + keys {
>> + status = "disabled";
>
> Like above: If it's broken, remove it, so nobody enables it accidentally and
> causes harm.
> (But document how to set it up in the commit message, as you mostly did
> already ...)
Factoring out realization details to the commit message is quite
unusual, I personally assume that the commit message is a place where
a committer should describe reasons for a particular change. While
hard to understand things should be commented on in the code themself.
I agree with Adrian that a not yet finished code should not be
committed to the master branch. But the device tree has a dualistic
nature, on one hand it is a place for driver configuration, on the
other hand it is a way to document board stuff interconnections. So
maybe we should combine Denise's approach to document even a not yet
fully supported component in the DTS with Adrian's suggestion to
document why a component is not supported yet and place the reason to
disable DTS node as comment inside the node? E.g.:
8< ---
keys {
compatible = "gpio-keys-polled";
reset {
...
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
/*
* GPIO line #15 is shared between the reset button on input and
* the NAND ALE (via the latch) on output. We are unable to just
* enable the reset button. So, this node here is for
* documentation purposes only.
*
* [Here should be a text describing the possible ways to
* overcome shared line issues]
*/
status = "disabled";
};
};
8< ---
This way we will keep all interconnection documentation in DTS and at
the same time we will make sure that no sane user enables this node.
> > + compatible = "gpio-keys";
> > + reset {
> > + label = "reset";
> > + linux,code = ;
> > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> > + debounce-interval = <60>;
> > + };
> > + };
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote:
> rb91x-ngl (nand-gpio-latch) requests and controls SoC GPIO
> lines that are used for NAND control and data lines multiplexed
> with a latch. Lines of the latch that are not used for NAND
> control lines, are used for power LED and user LED and a Shift
> Register nCS.
>
> Like rb4xx-cpld driver rb91x-ngl provides API for separate
> NAND driver and latch-GPIO driver.
>
> This driver is used in place of the ar71xx gpio-latch driver.
When I thought about porting RB91x code to the ath79 target, I also
had assumed as well as you that the parent MFD device is a good choice
to model the latch functionality. But after reviewing the
implementation of this idea, I would like to discuss another design
option. Maybe we should follow the original Gabor's approach and
implement the latch driver as a GPIO controller, but in a bit more
clean way?
For this board, the MFD type latch driver substitutes the common GPIO
API with a custom GPIO API and still knows too much about NAND lines.
If we model the latch as a GPIO controller, then it will consume 9
GPIO lines and produce 17 new GPIO lines. 8 consumed lines are for the
latch data input and another one line for the latch enabled state
control. 17 produced GPIO lines will be used for: 8 GPIOs for NAND
data + 8 additional GPIOs (4 GPIOs for NAND control + 4 GPIOs for LEDs
and for SSR nCS) + 1 more line to control the latch enabled state from
the rb91x-nand driver. The latch enabling line should be passed
through the latch driver to make the driver aware about the latch chip
state to block access to the latched lines as earlier.
So DTS will looks like this:
--8<---
latch_gpio: gpio_latch {
compatible = "gpio-latch";
gpio-controller;
data-gpios = <&soc_gpio 0 ...>,
<&soc_gpio 1 ...>,
...
<&soc_gpio 15 ...>;
le-gpios = <&soc_gpio 11 ...>;
};
nand {
compatible = "mikrotik,rb91x-nand";
data-gpios = <&latch_gpio 0 ...>,
<&latch_gpio 1 ...>,
...
<&latch_gpio 7 ...>;
ctrl-gpios = <&latch_gpio 12 ...>, /* NAND RDY */
<&latch_gpio 13 ...>, /* NAND nCE */
<&latch_gpio 15 ...>, /* NAND ALE */
<&latch_gpio 14 ...>, /* NAND CLE */
<&soc_gpio 12 ...>, /* NAND nRW */
<&latch_gpio 11 ...>; /* NAND Read */
ctrl-latch-gpios = <&latch_gpio 16 ...>;
...
};
&spi {
...
cs-gpios = <0>, <&latch_gpio 8 ...>;
...
};
...
led_power {
gpios = <&latch_gpio 9 ...>;
};
led_user {
gpios = <&latch_gpio 10 ...>;
};
--8<---
Using this approach we need one less driver (no need for MFD). But we
lose the clear indication of the latch enabled state change operation
and return to the hook in the output value set handler of the latch
GPIO driver. Also the NAND controller node became a sibling of the
latch node in the DTS, so we partially loose hierarchy information.
Any thoughts?
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] ath79: add support of Mikrotik RouterBoard 91xG series
On Thu, May 6, 2021 at 7:32 PM Denis Kalashnikov wrote:
> + /*
> +* MFD: NAND plus GPIO-controller. They use/share SoC GPIO lines.
> Some of the
> +* GPIO lines are multiplexed by a 8-bit latch (LVC573).
> +* NAND is controlled by GPIO lines (bitbang), also some NAND control
> lines
> +* (nCE, ALE, CLE, READ) and data lines are multiplexed by a latch.
> So driver
> +* set control lines, enable latch ("latched them") and then transfer
> data.
> +* Several lines of the latch (not used for NAND control lines) are
> used
> +* as general-purpose GPIO. NAND ECC format is Mikrotik specific.
> +*/
> + /*
> +
> +---+
> +
> | |
> ++-+
> | |
> +| |
> | |
> +| |
> | |
> +| |
> | | 3-4 lines
> +| |
> | +
> +| G | 8 lines
> | 8-bit |GPIO
> +| P
> +---+-+ |
> (leds, SSR nCS)
> +| I | |
> | Latch |
> +| O | |
> | |
> +| s | |
> | LVC573 | 4 lines
> +| | |
> | +---+
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | | 8
> +---+ |
> +| | |
>|
> +| | | l
>|
> +| | | i
>|
> +| SoC| | n
>|
> +| | | e
>|
> +| | | s
> +--+|
> +| | | |
> ||
> +| | | |
> C ||
> +| | | |
> | nCE, CLE, ALE, |
> +| | | |
> O ++
> +| | | | D
> | READ
> +| | | |
> N |
> +| | | | A
> |
> +| | | | N A N D
> T |
> +| | +-+ T
> |
> +| | |
> R | nRW, RDY
> +| | | A
> +--+
> +| | |
> O | |
> +| | |
> | |
> +| | |
> L | |
> +| | |
> | |
> +| G | |
> | |
> +| P |
> +--+ |
> +| I | 2 lines
> |
> +|
Re: [PATCH 2/4] ath79: add GPIO-latch driver for Mikrotik RB91xG
On Thu, May 6, 2021 at 7:32 PM Denis Kalashnikov wrote:
[skipped]
> +#define DRIVER_NAME "rb91x-gpio-latch"
Maybe just "rb91x-gpio"? Looks like this board has no more crazy GPIO
controllers.
> +static int get(struct gpio_chip *gc, unsigned offset)
> +{
> + return -ENOSYS;
> +}
[skipped]
> +static int direction_input(struct gpio_chip *gc, unsigned offset)
> +{
> + return -ENOSYS;
> +}
Just drop these two callbacks and gpiolib will care about attempts to
toggle line direction to input on the output-only controller.
> +
> +static int direction_output(struct gpio_chip *gc, unsigned offset, int value)
Use driver name as function prefix.
> +{
> + struct rb91x_ngl *ngl = gpiochip_get_data(gc);
> +
> + ngl->latch_gpio_set_value(ngl, offset, value);
> +
> + return 0;
> +}
> +
> +static int probe(struct platform_device *pdev)
ditto
> +{
> + struct gpio_chip *gc;
> + struct device_node *of_node = pdev->dev.of_node;
> + struct device *dev = &pdev->dev, *parent = pdev->dev.parent;
> + struct rb91x_ngl *ngl;
> + int ret;
> + u32 val;
> +
> + pr_info(DRIVER_NAME " driver probe\n");
Remove this custom trace on final submission.
> +
> + if (!parent)
> + return -ENODEV;
> +
> + gc = devm_kzalloc(&pdev->dev, sizeof(*gc), GFP_KERNEL);
> + if (!gc)
> + return -ENOMEM;
> +
> + /*
> + ret = of_property_read_u32(of_node, "base", &val);
> + if (ret < 0) {
> + dev_err(dev, "Could not read required 'base' property\n");
> + return -EINVAL;
> + }
> + pr_info(DRIVER_NAME ": base = %d\n", val);
> + gc->base = val;
> + */
> + gc->base = -1; /* Request dynamic allocation */
> +
> + ngl = dev_get_drvdata(parent);
> + if (!ngl) {
> + pr_err(DRIVER_NAME " ngl is null\n");
dev_err(dev, ...)
> + return -EINVAL;
> + }
> +
> + gc->label = DRIVER_NAME;
> + gc->parent = dev;
> + gc->can_sleep = true;
> + gc->ngpio = ngl->latch_gpios_count(ngl);
> + gc->get = get;
> + gc->set = set;
> + gc->direction_input = direction_input,
> + gc->direction_output = direction_output;
> + gc->of_node = of_node;
> +
> + platform_set_drvdata(pdev, gc);
> +
> + ret = gpiochip_add_data(gc, ngl);
> + if (ret) {
> + pr_err(DRIVER_NAME ": failed to add gpio chip: %d\n", ret);
dev_err(dev, ...)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int remove(struct platform_device *pdev)
> +{
> + gpiochip_remove(platform_get_drvdata(pdev));
> + return 0;
> +}
> +
> +static const struct of_device_id match[] = {
Use the driver name as prefix for global variables too.
> + { .compatible = "mikrotik," DRIVER_NAME },
> + {},
> +};
--
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote:
> rb91x-ngl (nand-gpio-latch)
I would like to suggest rename it to 'rb91x-latch'. This driver has no
NAND or GPIO functionality. Looks like it just multiplexes access to
subordinate HW, what is clearly indicated by the device tree, where
the latch is a parent for NAND and GPIO nodes. Besides this, the
'latch' name already looks puzzling, while using NGL abbreviation adds
another layer of puzzling. See referenced 'rb41x-cpld' driver. IMHO it
utilizes a perfect naming scheme.
> requests and controls SoC GPIO
> lines that are used for NAND control and data lines multiplexed
> with a latch. Lines of the latch that are not used for NAND
> control lines, are used for power LED and user LED and a Shift
> Register nCS.
As a common note, you are using the legacy GPIO API. Please use modern
API from linux/gpio/consumer.h
> Like rb4xx-cpld driver rb91x-ngl provides API for separate
> NAND driver and latch-GPIO driver.
>
> This driver is used in place of the ar71xx gpio-latch driver.
>
> Signed-off-by: Denis Kalashnikov
> ---
> .../linux/ath79/files/drivers/mfd/rb91x-ngl.c | 331 ++
> .../linux/ath79/files/include/mfd/rb91x-ngl.h | 59
> target/linux/ath79/mikrotik/config-default| 1 +
> .../patches-5.4/939-mikrotik-rb91x.patch | 21 ++
> 4 files changed, 412 insertions(+)
> create mode 100644 target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> create mode 100644 target/linux/ath79/files/include/mfd/rb91x-ngl.h
> create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch
>
> diff --git a/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> b/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> new file mode 100644
> index 00..c6ab4631f5
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> @@ -0,0 +1,331 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD driver for the MikroTik RouterBoard NAND controlled through GPIO
> + * multiplexed with latch. Why MFD, not pure NAND driver? Since the latch
> + * lines, that are not used for NAND control lines, are used for GPIO
> + * output function -- for leds and other.
> + *
> + * Copyright (C) 2021 Denis Kalashnikov
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define DRIVER_NAME "rb91x-nand-gpio-latch"
> +
> +#define NAND_DATAS 8
> +#define LATCH_GPIOS 3
> +
> +static int nand_datas_count(struct rb91x_ngl *ngl)
> +{
> + return NAND_DATAS;
> +}
> +
> +static int latch_gpios_count(struct rb91x_ngl *ngl)
> +{
> + return LATCH_GPIOS;
> +}
Should this information be provided in the runtime? You could move
NAND_DATAS and LATCH_GPIOS definitions to the common header file and
use them directly in the subordinate device drivers.
> +static void latch_lock(struct rb91x_ngl *ngl)
Please use a driver name as a common prefix for each driver function,
e.g. rb91x_latch_lock(). When someone sees a call for this function,
the prefix helps to distinguish whether it is a generic kernel
function call or some driver specific routine invocation. Also such
prefixing helps to avoid naming conflicts with generic kernel symbols.
> +{
> + mutex_lock(&ngl->mutex);
> +
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_NLE], 0);
> +}
> +
> +static void latch_unlock(struct rb91x_ngl *ngl)
ditto
> +{
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_NLE], 1);
> +
> + mutex_unlock(&ngl->mutex);
> +}
You could add a 'bool lock' argument and combine these two functions
into one to reduce the API a bit.
> +
> +#define OFFSET_INVAL(offset) ((offset) < 0 || (offset) >= RB91X_NGL_GPIOS)
You can define the 'offset' argument as an unsigned integer to avoid
checking for negative value. As for upper range bound, it is better to
check not against a constant that was used to define an array size,
but against the actual array size if array is static:
if (offset >= ARRAY_SIZE(ngl->gpio))
This is more flexible, clearly indicates the purpose of a check (i.e.
self descriptive) and is less error prone.
> +static void rb91x_ngl_gpio_set_value(struct rb91x_ngl *ngl, int offset, int
> val)
> +{
> + if (OFFSET_INVAL(offset))
> + return;
If you simplify the offset validation as I suggested above, then maybe
it is better to avoid macro usage and do the check explicitly to keep
code clear? E.g.
if (offset >= ARRAY_SIZE(ngl->gpio))
return;
> + gpio_set_value_cansleep(ngl->gpio[offset], val);
> +}
> +
> +static void latch_gpio_set_value(struct rb91x_ngl *ngl, int offset, int val)
> +{
> + if (offset >= LATCH_GPIOS)
> + return;
> +
> + mutex_lock(&ngl->mutex);
> +
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_LATCH_GPIO0 + offset],
> val);
> +
> + mutex_unlock(&ngl->mutex);
> +}
> +
> +static int rb91x_ngl_gpio_get_value(struct rb91x_ngl *ngl, int offset)
> +{
> + if (OFFSET_INVAL(offset))
> +
Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG
Hello Denis, On Thu, May 6, 2021 at 7:31 PM Denis Kalashnikov wrote: > When porting RB91xG ad hoc drivers (gpio-latch and rb91x-nand) from ar71xx > to ath79, I made a decision to rework this to more clear design in my opinion: > MFD driver that requests and controls the gpio lines, and separate NAND > driver and GPIO-latch driver that uses API of the MFD driver (like > how in rb4xx-clpd is done). ar71xx gpio-latch is very good, but somewhat > hacky, > so I don't think that it can be general driver for gpio controller on a latch. > I could be wrong. Also it is my first attempt to port OpenWrt to a device, so > I need a review from the community. I've tested all these on my > RB912UAG-2HPnD. > Gigabit Ethernet, 2.4GHz Wi-Fi, sysupgrade and LEDs:) are working for me. > Not working: beeper, button and USB port/mPCIe (has not tested yet). Thank you for this considerable work! Besides the per patch comments, please check checkpatch.pl report, it produces some useful inputs. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: Fix for Mikrotik NAND bad blocks - testers needed
Hello Danijel, On Tue, Mar 23, 2021 at 3:21 PM Sergey Ryazanov wrote: > On Mon, Mar 22, 2021 at 11:54 PM Danijel wrote: >> So now I'm looking for testers (and reviewers) who could test this change on >> the affected devices (with bad blocks) and NOR Mikrotiks. > > I have a couple of RB433 boards somewhere with BB in the kernel area. > I will try to find them and test with your changes. I found mentioned boards, but they in fact were RB411U. Each of them have bad blocks in the kernel area and so they are unable to work with OpenWrt 19.07. I am stuck with running master ath79 on it. Board bootloader rejects to boot an initramfs kernel. Looks like this happened due to its size. I am beginning to switch to lzma-loader, but faced some decompression issues and need some more time to be able to test your patches. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: Fix for Mikrotik NAND bad blocks - testers needed
Hello Danijel! On Mon, Mar 22, 2021 at 11:54 PM Danijel wrote: > I'm working on restoring Mikrotik RB2011 support after ar71xx target was > dropped after 19.07 release. While working on it, the problem with bad blocks > and the issue of the current way of flashing kernel was also brought up. > > Right now, for Mikrotiks we use kernel2minor which generates a 4MiB YAFFS2 > partition image holding the kernel binary. > This method can't take NAND bad blocks in the kernel partition area into > account, and if there are any, flashing fails and the device is usable only > for RouterOS, because YAFFS2 support was removed from OpenWrt a few years ago. > > I was able to re-add YAFFS2 driver and limit it only to Mikrotik builds of > ath79 target, and in my tests it properly mounts the kernel partition and > replaces the kernel binary. However, I don't have a device with bad blocks in > the kernel area so I can't confirm if it will properly handle them, although > it should work unless the upstream driver (or Kconfig) is messed up. Thank you for taking care of this. Missing of YAFFS2 support causes more issues besides the bad block in the kernel area. E.g. 'large' and '64m' images for boards with different block formats. So I am for YAFFS2 support! > So now I'm looking for testers (and reviewers) who could test this change on > the affected devices (with bad blocks) and NOR Mikrotiks. I have a couple of RB433 boards somewhere with BB in the kernel area. I will try to find them and test with your changes. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath25: fix preinit Ethernet port configuration
On Wed, Sep 9, 2020 at 6:08 PM Adrian Schmutzler wrote: > > - vconfig add eth0 1 > > + ip link add dev eth0.1 link eth0 type vlan id > > 1 > > Are you sure this is correct? Yes, I tested this command with an OpenWrt ip package :) > I only find the following syntax: > > ip link add link eth0 name eth0.1 type vlan id 1 > According to ip-link(8) a user should use 'name' argument for a new interface, but in fact the iplink.c have the following code in the interface creation handler: > /* Allow "ip link add dev" and "ip link add name" */ >if (!name) >name = dev; -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/5] ath25: return back with 5.4 kernel support
On Sun, Sep 6, 2020 at 6:32 PM Adrian Schmutzler wrote: > I have pushed my to-be-merged collection of patches here: > https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/ath25merge Thank you for this careful work! Commit that recovers 4.14 patches, but within the 5.4 directory is a very nice solution for revert-drop-and-anyway-drop case. > However, before I can merge this, we still need somebody to clean up > base-files/lib/preinit/15_preinit_iface_atheros > > This still contains calls to vconfig which is not added by default for years. > > Somebody just send it separately and then I will put it on top. Just sent a patch that fixes this. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath25: fix preinit Ethernet port configuration
vconfig is no more installed by default to a firmware image. So, replace
vconfig calls for VLAN subinterface configuration by coresponding
ip-link commands.
Also drop few useless comments from the preinit hook script, while we
are at it.
I have no chance to test this fix since I have no board with a subject
switch IC, but this is still better then call an utility that is
unavailable in the firmware for years.
Signed-off-by: Sergey Ryazanov
---
.../base-files/lib/preinit/15_preinit_iface_atheros | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
b/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
index 235ba4befc..87bc4abba5 100644
--- a/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
+++ b/target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros
@@ -1,12 +1,10 @@
-# reset button only supported on ar5315+ at the moment
preinit_ip() {
if [ -z "$pi_ifname" ]; then
grep -q 'Atheros AR231[567]' /proc/cpuinfo && {
if [ -e "/sys/bus/mdio_bus/drivers/Infineon
ADM6996/0:00" -o \
-e "/sys/bus/mdio_bus/drivers/Marvell
88E6060/0:10" ]; then
- vconfig set_name_type DEV_PLUS_VID_NO_PAD
ip link set eth0 up
- vconfig add eth0 1
+ ip link add dev eth0.1 link eth0 type vlan id 1
ifname=eth0.1
else
ifname=eth0
@@ -20,13 +18,10 @@ preinit_ip() {
}
}
-
-# reset button only supported on ar5315+ at the moment
-
preinit_ip_deconfig() {
if [ -e "/sys/bus/mdio_bus/drivers/Infineon ADM6996/0:00" -o \
-e "/sys/bus/mdio_bus/drivers/Marvell 88E6060/0:10" ]; then
- vconfig rem eth0.1 2>/dev/null
+ ip link del eth0.1 2>/dev/null
ip link set $pi_ifname down
elif [ -n "$pi_ifname" ]; then
ip -4 addr flush dev $pi_ifname
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/5] ath25: return back with 5.4 kernel support
On Sat, Sep 5, 2020 at 10:36 AM Adrian Schmutzler wrote: > > This series returns back ath25 target and switches it to 5.4 kernel. > > I will take care, but probably alter the patches so we directly start with > kernel 5.4, and not add back 4.14 just to remove it again. Sure. But specify the commit which drops ath25 target with 4.14 kernel in a commit message, please. So, history readers will be aware of reasons of history interruption and where history is continued. -- Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/5] Revert "ath25: drop target"
This reverts commit 7d29a557140381ef1815329f6843b88b4126d490. Discussion in the mailing list reveals that this target have active users. Also we are able to uprgade this target to 5.4 kernel, so resurect the target first by reverting the commit. Signed-off-by: Sergey Ryazanov --- package/kernel/mac80211/ath.mk| 10 +- target/linux/ath25/Makefile | 24 + .../ath25/base-files/etc/board.d/01_leds | 13 + .../ath25/base-files/etc/board.d/02_network | 28 + .../lib/preinit/15_preinit_iface_atheros | 34 + .../ath25/base-files/lib/upgrade/platform.sh | 76 + target/linux/ath25/config-4.14| 170 ++ target/linux/ath25/image/Makefile | 115 ++ .../ath25/patches-4.14/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-4.14/108-ar2315_gpio.patch | 363 .../patches-4.14/110-ar2313_ethernet.patch| 1734 + .../ath25/patches-4.14/120-spiflash.patch | 634 ++ .../ath25/patches-4.14/130-watchdog.patch | 277 +++ .../140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-4.14/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-4.14/330-board_leds.patch | 116 ++ target/linux/ath25/profiles/00-default.mk | 16 + 20 files changed, 4177 insertions(+), 3 deletions(-) create mode 100644 target/linux/ath25/Makefile create mode 100755 target/linux/ath25/base-files/etc/board.d/01_leds create mode 100755 target/linux/ath25/base-files/etc/board.d/02_network create mode 100644 target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros create mode 100644 target/linux/ath25/base-files/lib/upgrade/platform.sh create mode 100644 target/linux/ath25/config-4.14 create mode 100644 target/linux/ath25/image/Makefile create mode 100644 target/linux/ath25/patches-4.14/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-4.14/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-4.14/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-4.14/120-spiflash.patch create mode 100644 target/linux/ath25/patches-4.14/130-watchdog.patch create mode 100644 target/linux/ath25/patches-4.14/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-4.14/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-4.14/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-4.14/210-reset_button.patch create mode 100644 target/linux/ath25/patches-4.14/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-4.14/330-board_leds.patch create mode 100644 target/linux/ath25/profiles/00-default.mk diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk index 45037738de..5db4be8daa 100644 --- a/package/kernel/mac80211/ath.mk +++ b/package/kernel/mac80211/ath.mk @@ -55,7 +55,11 @@ config-$(call config_package,ath9k-htc) += ATH9K_HTC config-$(call config_package,ath10k) += ATH10K ATH10K_PCI config-$(call config_package,ath5k) += ATH5K -config-y += ATH5K_PCI +ifdef CONFIG_TARGET_ath25 + config-y += ATH5K_AHB +else + config-y += ATH5K_PCI +endif config-$(call config_package,ath6kl) += ATH6KL config-$(call config_package,ath6kl-sdio) += ATH6KL_SDIO @@ -117,7 +121,7 @@ endef define KernelPackage/ath $(call KernelPackage/mac80211/Default) TITLE:=Atheros common driver part - DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ath79 +kmod-mac80211 + DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ath79||TARGET_ath25 +kmod-mac80211 FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath.ko MENU:=1 endef @@ -130,7 +134,7 @@ define KernelPackage/ath5k $(call KernelPackage/mac80211/Default) TITLE:=Atheros 5xxx wireless cards support URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath5k - DEPENDS+= @PCI_SUPPORT +kmod-ath +@DRIVER_11W_SUPPORT + DEPENDS+= @(PCI_SUPPORT||TARGET_ath25) +kmod-ath +@DRIVER_11W_SUPPORT FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath5k/ath5k.ko AUTOLOAD:=$(call AutoProbe,ath5k) endef diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile new file mode 100644 index 00..f885112460 --- /dev/null +++ b/target/linux/ath25/Makefile @@ -0,0 +1,24 @@ +# +# Copyright (C) 2006-2013 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# +include $(TOPDIR)/rules.mk + +ARCH:=mips +BOARD:=ath25 +BOARDNAME:=Atheros AR231x/AR5312 +FEATURES:=squashfs low_mem small_flash + +KERNEL_PATCHVER:=4.14 + +define Target/Description + Build firmware images for Atheros SoC boards +endef + +include $(INCLUDE_DIR)/target.mk + +DEFAULT_PACKAGES += wpad-basic-wolfssl kmod-ath5k swconfig kmod-gpio-button-hotplug + +$(eval $(call
[PATCH 5/5] ath25: drop 4.14 kernel support
Remove no more used 4.14 kernel support. Signed-off-by: Sergey Ryazanov --- target/linux/ath25/config-4.14| 170 -- .../ath25/patches-4.14/107-ar5312_gpio.patch | 212 -- .../ath25/patches-4.14/108-ar2315_gpio.patch | 363 .../patches-4.14/110-ar2313_ethernet.patch| 1734 - .../ath25/patches-4.14/120-spiflash.patch | 634 -- .../ath25/patches-4.14/130-watchdog.patch | 277 --- .../140-redboot_boardconfig.patch | 60 - .../141-redboot_partition_scan.patch | 44 - .../142-redboot_various_erase_size_fix.patch | 72 - .../ath25/patches-4.14/210-reset_button.patch | 71 - .../220-enet_micrel_workaround.patch | 111 -- .../ath25/patches-4.14/330-board_leds.patch | 116 -- 12 files changed, 3864 deletions(-) delete mode 100644 target/linux/ath25/config-4.14 delete mode 100644 target/linux/ath25/patches-4.14/107-ar5312_gpio.patch delete mode 100644 target/linux/ath25/patches-4.14/108-ar2315_gpio.patch delete mode 100644 target/linux/ath25/patches-4.14/110-ar2313_ethernet.patch delete mode 100644 target/linux/ath25/patches-4.14/120-spiflash.patch delete mode 100644 target/linux/ath25/patches-4.14/130-watchdog.patch delete mode 100644 target/linux/ath25/patches-4.14/140-redboot_boardconfig.patch delete mode 100644 target/linux/ath25/patches-4.14/141-redboot_partition_scan.patch delete mode 100644 target/linux/ath25/patches-4.14/142-redboot_various_erase_size_fix.patch delete mode 100644 target/linux/ath25/patches-4.14/210-reset_button.patch delete mode 100644 target/linux/ath25/patches-4.14/220-enet_micrel_workaround.patch delete mode 100644 target/linux/ath25/patches-4.14/330-board_leds.patch diff --git a/target/linux/ath25/config-4.14 b/target/linux/ath25/config-4.14 deleted file mode 100644 index 734f598cd0..00 --- a/target/linux/ath25/config-4.14 +++ /dev/null @@ -1,170 +0,0 @@ -CONFIG_ADM6996_PHY=y -CONFIG_AR2315_WDT=y -CONFIG_AR8216_PHY=y -CONFIG_ARCH_BINFMT_ELF_STATE=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_DISCARD_MEMBLOCK=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -# CONFIG_ARCH_HAS_GCOV_PROFILE_ALL is not set -# CONFIG_ARCH_HAS_SG_CHAIN is not set -# CONFIG_ARCH_HAS_STRICT_KERNEL_RWX is not set -# CONFIG_ARCH_HAS_STRICT_MODULE_RWX is not set -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y -CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y -CONFIG_ARCH_MMAP_RND_BITS_MAX=15 -CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set -# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set -CONFIG_ARCH_SUPPORTS_UPROBES=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y -CONFIG_ATH25=y -CONFIG_BLK_MQ_PCI=y -CONFIG_CEVT_R4K=y -CONFIG_CLONE_BACKWARDS=y -CONFIG_CMDLINE="console=ttyS0,9600 rootfstype=squashfs,jffs2" -CONFIG_CMDLINE_BOOL=y -# CONFIG_CMDLINE_OVERRIDE is not set -CONFIG_CPU_BIG_ENDIAN=y -CONFIG_CPU_GENERIC_DUMP_TLB=y -CONFIG_CPU_HAS_PREFETCH=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_CPU_MIPS32=y -CONFIG_CPU_MIPS32_R1=y -CONFIG_CPU_MIPSR1=y -CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y -CONFIG_CPU_R4K_CACHE_TLB=y -CONFIG_CPU_R4K_FPU=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_HIGHMEM=y -CONFIG_CRYPTO_RNG2=y -CONFIG_CRYPTO_WORKQUEUE=y -CONFIG_CSRC_R4K=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_EARLY_PRINTK=y -CONFIG_ETHERNET_PACKET_MANGLE=y -CONFIG_GENERIC_ATOMIC64=y -CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_CPU_AUTOPROBE=y -CONFIG_GENERIC_IO=y -CONFIG_GENERIC_IRQ_CHIP=y -CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y -CONFIG_GENERIC_IRQ_SHOW=y -CONFIG_GENERIC_PCI_IOMAP=y -CONFIG_GENERIC_SCHED_CLOCK=y -CONFIG_GENERIC_SMP_IDLE_THREAD=y -CONFIG_GENERIC_TIME_VSYSCALL=y -CONFIG_GPIOLIB=y -CONFIG_GPIO_AR2315=y -CONFIG_GPIO_AR5312=y -# CONFIG_GRO_CELLS is not set -CONFIG_HANDLE_DOMAIN_IRQ=y -CONFIG_HARDWARE_WATCHPOINTS=y -CONFIG_HAS_DMA=y -CONFIG_HAS_IOMEM=y -CONFIG_HAS_IOPORT_MAP=y -# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set -# CONFIG_HAVE_ARCH_BITREVERSE is not set -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set -CONFIG_HAVE_CBPF_JIT=y -CONFIG_HAVE_CC_STACKPROTECTOR=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_API_DEBUG=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LATENCYTOP_SUPPORT=y -CONFIG_HAVE_MEMBLOCK=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE
[PATCH 2/5] ath25: add kernel 5.4 support
Copy and refresh patches and config from 4.14. The only couple of fixes
required to make kernel buildable:
* rework ethernet supported link modes to linkmode bitmask;
* drop erase callback invocation from AR2315 MTD driver.
Signed-off-by: Sergey Ryazanov
---
target/linux/ath25/Makefile | 1 +
.../linux/ath25/{config-4.14 => config-5.4} | 73 +++
.../107-ar5312_gpio.patch | 20 ++---
.../108-ar2315_gpio.patch | 18 ++---
.../110-ar2313_ethernet.patch | 30
.../120-spiflash.patch| 9 +--
.../130-watchdog.patch| 4 +-
.../140-redboot_boardconfig.patch | 14 ++--
.../141-redboot_partition_scan.patch} | 8 +-
.../142-redboot_various_erase_size_fix.patch | 16 ++--
.../210-reset_button.patch| 0
.../220-enet_micrel_workaround.patch | 0
.../330-board_leds.patch | 0
13 files changed, 101 insertions(+), 92 deletions(-)
copy target/linux/ath25/{config-4.14 => config-5.4} (76%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/107-ar5312_gpio.patch
(92%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/108-ar2315_gpio.patch
(95%)
copy target/linux/ath25/{patches-4.14 =>
patches-5.4}/110-ar2313_ethernet.patch (98%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/120-spiflash.patch (98%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/130-watchdog.patch (98%)
copy target/linux/ath25/{patches-4.14 =>
patches-5.4}/140-redboot_boardconfig.patch (81%)
copy target/linux/{ath79/patches-5.4/408-mtd-redboot_partition_scan.patch =>
ath25/patches-5.4/141-redboot_partition_scan.patch} (79%)
copy target/linux/ath25/{patches-4.14 =>
patches-5.4}/142-redboot_various_erase_size_fix.patch (81%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/210-reset_button.patch
(100%)
copy target/linux/ath25/{patches-4.14 =>
patches-5.4}/220-enet_micrel_workaround.patch (100%)
copy target/linux/ath25/{patches-4.14 => patches-5.4}/330-board_leds.patch
(100%)
diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile
index f885112460..0ed40bd54b 100644
--- a/target/linux/ath25/Makefile
+++ b/target/linux/ath25/Makefile
@@ -12,6 +12,7 @@ BOARDNAME:=Atheros AR231x/AR5312
FEATURES:=squashfs low_mem small_flash
KERNEL_PATCHVER:=4.14
+KERNEL_TESTING_PATCHVER:=5.4
define Target/Description
Build firmware images for Atheros SoC boards
diff --git a/target/linux/ath25/config-4.14 b/target/linux/ath25/config-5.4
similarity index 76%
copy from target/linux/ath25/config-4.14
copy to target/linux/ath25/config-5.4
index 734f598cd0..f59f48f655 100644
--- a/target/linux/ath25/config-4.14
+++ b/target/linux/ath25/config-5.4
@@ -1,26 +1,26 @@
CONFIG_ADM6996_PHY=y
CONFIG_AR2315_WDT=y
CONFIG_AR8216_PHY=y
-CONFIG_ARCH_BINFMT_ELF_STATE=y
+CONFIG_ARCH_32BIT_OFF_T=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
-CONFIG_ARCH_DISCARD_MEMBLOCK=y
+CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y
+CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
+CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
-# CONFIG_ARCH_HAS_GCOV_PROFILE_ALL is not set
-# CONFIG_ARCH_HAS_SG_CHAIN is not set
-# CONFIG_ARCH_HAS_STRICT_KERNEL_RWX is not set
-# CONFIG_ARCH_HAS_STRICT_MODULE_RWX is not set
+CONFIG_ARCH_HAS_PHYS_TO_DMA=y
+CONFIG_ARCH_HAS_PTE_SPECIAL=y
+CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
+CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
-CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
-CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_ARCH_MMAP_RND_BITS_MAX=15
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15
-# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set
-# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
+CONFIG_ARCH_USE_MEMREMAP_PROT=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
+CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_ATH25=y
CONFIG_BLK_MQ_PCI=y
@@ -29,8 +29,10 @@ CONFIG_CLONE_BACKWARDS=y
CONFIG_CMDLINE="console=ttyS0,9600 rootfstype=squashfs,jffs2"
CONFIG_CMDLINE_BOOL=y
# CONFIG_CMDLINE_OVERRIDE is not set
+CONFIG_COMPAT_32BIT_TIME=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_CPU_GENERIC_DUMP_TLB=y
+CONFIG_CPU_HAS_LOAD_STORE_LR=y
CONFIG_CPU_HAS_PREFETCH=y
CONFIG_CPU_HAS_SYNC=y
CONFIG_CPU_MIPS32=y
@@ -38,23 +40,34 @@ CONFIG_CPU_MIPS32_R1=y
CONFIG_CPU_MIPSR1=y
CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y
CONFIG_CPU_R4K_CACHE_TLB=y
-CONFIG_CPU_R4K_FPU=y
CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_HIGHMEM=y
CONFIG_CRYPTO_RNG2=y
-CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CSRC_R4K=y
CONFIG_DMA_NONCOHERENT=y
+CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y
CONFIG_EARLY_PRINTK=y
+CONFIG_EFI_EARLYCON=y
CONFIG_ETHERNET_PACKET_MANGLE=y
+CONFIG_FONT_8x16=y
+CONFIG_FONT_AUTOSE
[PATCH 0/5] ath25: return back with 5.4 kernel support
This series returns back ath25 target and switches it to 5.4 kernel. Discussion in the mailing list revealed that this target still has active users and some boards still have enough Flash/RAM. We are able to upgrade target to a fresh kernel and there are no objection against a target recovery. So, lets return the ath25 target back for at least the next release circle. Compile- and run-tested with the following boards: * D-Link DIR-300 A1 (AR2317) * D-Link DWL-2100AP (AR2313) Partially tested with Fonera FON2201 (AR2315 based). My single board has misteriously bricked during a routine sysupgrade (power issue?). But Ethernet and Wi-Fi interfaces were tested and work as expected. Sergey Ryazanov (5): Revert "ath25: drop target" ath25: add kernel 5.4 support ath25: eth: fix crash on skb DMA (un-)map ath25: switch to 5.4 kernel ath25: drop 4.14 kernel support package/kernel/mac80211/ath.mk| 10 +- target/linux/ath25/Makefile | 25 + .../ath25/base-files/etc/board.d/01_leds | 13 + .../ath25/base-files/etc/board.d/02_network | 28 + .../lib/preinit/15_preinit_iface_atheros | 34 + .../ath25/base-files/lib/upgrade/platform.sh | 76 + target/linux/ath25/config-5.4 | 181 ++ target/linux/ath25/image/Makefile | 115 ++ .../ath25/patches-5.4/107-ar5312_gpio.patch | 212 ++ .../ath25/patches-5.4/108-ar2315_gpio.patch | 363 .../patches-5.4/110-ar2313_ethernet.patch | 1736 + .../ath25/patches-5.4/120-spiflash.patch | 631 ++ .../ath25/patches-5.4/130-watchdog.patch | 277 +++ .../patches-5.4/140-redboot_boardconfig.patch | 60 + .../141-redboot_partition_scan.patch | 44 + .../142-redboot_various_erase_size_fix.patch | 72 + .../ath25/patches-5.4/210-reset_button.patch | 71 + .../220-enet_micrel_workaround.patch | 111 ++ .../ath25/patches-5.4/330-board_leds.patch| 116 ++ target/linux/ath25/profiles/00-default.mk | 16 + 20 files changed, 4188 insertions(+), 3 deletions(-) create mode 100644 target/linux/ath25/Makefile create mode 100755 target/linux/ath25/base-files/etc/board.d/01_leds create mode 100755 target/linux/ath25/base-files/etc/board.d/02_network create mode 100644 target/linux/ath25/base-files/lib/preinit/15_preinit_iface_atheros create mode 100644 target/linux/ath25/base-files/lib/upgrade/platform.sh create mode 100644 target/linux/ath25/config-5.4 create mode 100644 target/linux/ath25/image/Makefile create mode 100644 target/linux/ath25/patches-5.4/107-ar5312_gpio.patch create mode 100644 target/linux/ath25/patches-5.4/108-ar2315_gpio.patch create mode 100644 target/linux/ath25/patches-5.4/110-ar2313_ethernet.patch create mode 100644 target/linux/ath25/patches-5.4/120-spiflash.patch create mode 100644 target/linux/ath25/patches-5.4/130-watchdog.patch create mode 100644 target/linux/ath25/patches-5.4/140-redboot_boardconfig.patch create mode 100644 target/linux/ath25/patches-5.4/141-redboot_partition_scan.patch create mode 100644 target/linux/ath25/patches-5.4/142-redboot_various_erase_size_fix.patch create mode 100644 target/linux/ath25/patches-5.4/210-reset_button.patch create mode 100644 target/linux/ath25/patches-5.4/220-enet_micrel_workaround.patch create mode 100644 target/linux/ath25/patches-5.4/330-board_leds.patch create mode 100644 target/linux/ath25/profiles/00-default.mk -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/5] ath25: eth: fix crash on skb DMA (un-)map
AR2315 Ethernet driver pass NULL instead of a real device pointer to DMA
(un-)map calls. With kernel version 5.4 such behaviour causes a kernel
panic. Fix this issue by preserving device pointer during the probe
procedure and pass it to each skb data DMA (un-)map call.
Signed-off-by: Sergey Ryazanov
---
.../linux/ath25/patches-5.4/110-ar2313_ethernet.patch | 10 ++
.../ath25/patches-5.4/220-enet_micrel_workaround.patch | 10 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/target/linux/ath25/patches-5.4/110-ar2313_ethernet.patch
b/target/linux/ath25/patches-5.4/110-ar2313_ethernet.patch
index e4f5fa8d2e..57c18abf69 100644
--- a/target/linux/ath25/patches-5.4/110-ar2313_ethernet.patch
+++ b/target/linux/ath25/patches-5.4/110-ar2313_ethernet.patch
@@ -33,7 +33,7 @@
+obj-$(CONFIG_NET_AR231X) += ar231x.o
--- /dev/null
+++ b/drivers/net/ethernet/atheros/ar231x/ar231x.c
-@@ -0,0 +1,1119 @@
+@@ -0,0 +1,1120 @@
+/*
+ * ar231x.c: Linux driver for the Atheros AR231x Ethernet device.
+ *
@@ -225,6 +225,7 @@
+
+ sp = netdev_priv(dev);
+ sp->dev = dev;
++ sp->pdev = pdev;
+ sp->cfg = pdev->dev.platform_data;
+
+ sprintf(buf, "eth%d_membase", pdev->id);
@@ -787,7 +788,7 @@
+ break;
+ }
+ /* done with this descriptor */
-+ dma_unmap_single(NULL, txdesc->addr,
++ dma_unmap_single(&sp->pdev->dev, txdesc->addr,
+ txdesc->devcs & DMA_TX1_BSIZE_MASK,
+ DMA_TO_DEVICE);
+ txdesc->status = 0;
@@ -1014,7 +1015,7 @@
+ /* Setup the transmit descriptor. */
+ td->devcs = ((skb->len << DMA_TX1_BSIZE_SHIFT) |
+ (DMA_TX1_LS | DMA_TX1_IC | DMA_TX1_CHAINED));
-+ td->addr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE);
++ td->addr = dma_map_single(&sp->pdev->dev, skb->data, skb->len,
DMA_TO_DEVICE);
+ td->status = DMA_TX_OWN;
+
+ /* kick transmitter last */
@@ -1155,7 +1156,7 @@
+
--- /dev/null
+++ b/drivers/net/ethernet/atheros/ar231x/ar231x.h
-@@ -0,0 +1,281 @@
+@@ -0,0 +1,282 @@
+/*
+ * ar231x.h: Linux driver for the Atheros AR231x Ethernet device.
+ *
@@ -1379,6 +1380,7 @@
+ */
+struct ar231x_private {
+ struct net_device *dev;
++ struct platform_device *pdev;
+ int version;
+ u32 mb[2];
+
diff --git a/target/linux/ath25/patches-5.4/220-enet_micrel_workaround.patch
b/target/linux/ath25/patches-5.4/220-enet_micrel_workaround.patch
index 91b9792515..9051e1b466 100644
--- a/target/linux/ath25/patches-5.4/220-enet_micrel_workaround.patch
+++ b/target/linux/ath25/patches-5.4/220-enet_micrel_workaround.patch
@@ -41,7 +41,7 @@
static int ar231x_probe(struct platform_device *pdev)
{
struct net_device *dev;
-@@ -273,6 +300,24 @@ static int ar231x_probe(struct platform_
+@@ -274,6 +301,24 @@ static int ar231x_probe(struct platform_
mdiobus_register(sp->mii_bus);
@@ -66,7 +66,7 @@
if (ar231x_mdiobus_probe(dev) != 0) {
printk(KERN_ERR "%s: mdiobus_probe failed\n", dev->name);
rx_tasklet_cleanup(dev);
-@@ -326,8 +371,10 @@ static int ar231x_remove(struct platform
+@@ -327,8 +372,10 @@ static int ar231x_remove(struct platform
rx_tasklet_cleanup(dev);
ar231x_init_cleanup(dev);
unregister_netdev(dev);
@@ -79,7 +79,7 @@
kfree(dev);
return 0;
}
-@@ -870,7 +917,8 @@ static int ar231x_open(struct net_device
+@@ -871,7 +918,8 @@ static int ar231x_open(struct net_device
sp->eth_regs->mac_control |= MAC_CONTROL_RE;
@@ -89,7 +89,7 @@
return 0;
}
-@@ -951,7 +999,8 @@ static int ar231x_close(struct net_devic
+@@ -952,7 +1000,8 @@ static int ar231x_close(struct net_devic
#endif
@@ -99,7 +99,7 @@
return 0;
}
-@@ -995,6 +1044,9 @@ static int ar231x_ioctl(struct net_devic
+@@ -996,6 +1045,9 @@ static int ar231x_ioctl(struct net_devic
{
struct ar231x_private *sp = netdev_priv(dev);
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] ath25: switch to 5.4 kernel
Switch to actual kernel version. Signed-off-by: Sergey Ryazanov --- target/linux/ath25/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile index 0ed40bd54b..3edbaf19b6 100644 --- a/target/linux/ath25/Makefile +++ b/target/linux/ath25/Makefile @@ -11,7 +11,7 @@ BOARD:=ath25 BOARDNAME:=Atheros AR231x/AR5312 FEATURES:=squashfs low_mem small_flash -KERNEL_PATCHVER:=4.14 +KERNEL_PATCHVER:=5.4 KERNEL_TESTING_PATCHVER:=5.4 define Target/Description -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
