Re: Re: [PATCH] ccache: don't use non-ASCII quotes

[David Adair via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
> I would rather prefer to disable[1] the documentation.
> 
> 1. https://github.com/ccache/ccache/pull/842

Thank you.  Zero maintenance is much better.

Since master has been updated to 4.2.1 which builds fine it seems no
change there is required until it also has this change.

Is there any interest in placing this in 21.02 along with the Makefile
c
hange to use it ?  The build failure is specific to ccache 4.1 and does
NOT occur using default config ( ccache and sdk disabled ).



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

Re: FRAG Attacks (new vuln for wifi)

[Felix Fietkau]

On 2021-05-13 01:45, Nick Lowe wrote:
>> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to 
>> > be patched?
>> > Is 4.19 the oldest that owrt will consume?
>> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
>> anything older than that.
> 
> So, to summarise, the 4.19, 5.4 and 5.10 branch kernels are currently in use.
I don't see where we're using the ath10k-ct 5.4 kernel at all. It should
be just 4.19 and 5.10.

- Felix

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

Re: FRAG Attacks (new vuln for wifi)

[Nick Lowe]

> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to 
> > be patched?
> > Is 4.19 the oldest that owrt will consume?
> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
> anything older than that.

So, to summarise, the 4.19, 5.4 and 5.10 branch kernels are currently in use.

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

[PATCH] openwrt-keyring: Only copy sign key for snapshots

[Hauke Mehrtens]

Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the master feeds.

If one of the other keys would be compromised this would not affect
users of master snapshot builds.

Signed-off-by: Hauke Mehrtens 
---

As far as I know the other keys are not compromised, this is just a 
precaution. 

I would do similar changes to 21.02 and 19.07 to only add the key which 
is used for this specific release.

Instead of adding just this single key, should we add all keys of 
currently maintained releases like 19.07, 21.02 and master key into all 
3 branches? 

The signature verification of sysupgrade images is currently not used as 
far as I know, so normal we do not need the keys for of other releases.


 package/system/openwrt-keyring/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/system/openwrt-keyring/Makefile 
b/package/system/openwrt-keyring/Makefile
index 6f3aa65622d5..ceaccf1fc527 100644
--- a/package/system/openwrt-keyring/Makefile
+++ b/package/system/openwrt-keyring/Makefile
@@ -32,7 +32,8 @@ Build/Compile=
 
 define Package/openwrt-keyring/install
$(INSTALL_DIR) $(1)/etc/opkg/keys/
-   $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/* $(1)/etc/opkg/keys/
+   # Public usign key for unattended snapshot builds
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/usign/b5043e70f9a75cde 
$(1)/etc/opkg/keys/
 endef
 
 $(eval $(call BuildPackage,openwrt-keyring))
-- 
2.30.2


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

[PATCH DRAFT RFC] upoe: tiny daemon for PoE devices

[Rafał Miłecki]

From: Rafał Miłecki 

This is a tiny app that reads list of PoE devices and initializes them
using built-in drivers. PoE status can be read using ubus.

Signed-off-by: Rafał Miłecki 
---
This is a *** DRAFT *** for how we could handle PoE devices in OpenWrt.
Please feel free to comment if this EARLY & INCOMPLETE design looks sane
enough.
---
 CMakeLists.txt |   9 
 dummy.c|  24 +
 upoe.c | 144 +
 upoe.h |  36 +
 4 files changed, 213 insertions(+)
 create mode 100644 CMakeLists.txt
 create mode 100644 dummy.c
 create mode 100644 upoe.c
 create mode 100644 upoe.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 000..6474663
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,9 @@
+cmake_minimum_required(VERSION 2.6)
+
+project(upoe)
+set(CMAKE_C_FLAGS "-std=c99 -D_GNU_SOURCE -Wall")
+
+add_executable(upoe upoe.c dummy.c)
+target_link_libraries(upoe ubox ubus uci)
+
+install(TARGETS upoe RUNTIME DESTINATION bin)
diff --git a/dummy.c b/dummy.c
new file mode 100644
index 000..de0abfb
--- /dev/null
+++ b/dummy.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "upoe.h"
+
+static int upoe_dummy_probe_device(struct upoe *upoe, struct uci_element *e)
+{
+   struct device *dev = calloc(1, sizeof(*dev));
+
+   dev->drv = 
+   upoe_device_register(upoe, dev);
+
+   return 0;
+}
+
+static int upoe_dummy_get_status(struct upoe *upoe, struct device *dev)
+{
+   return 0;
+}
+
+struct driver dummy = {
+   .type = "dummy",
+   .probe_device = upoe_dummy_probe_device,
+   .get_status = upoe_dummy_get_status,
+}; 
diff --git a/upoe.c b/upoe.c
new file mode 100644
index 000..3dfa834
--- /dev/null
+++ b/upoe.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "upoe.h"
+
+/**
+ * Device
+ **/
+
+static int upoe_device_status(struct ubus_context *ctx,
+ struct ubus_object *obj,
+ struct ubus_request_data *req,
+ const char *method,
+ struct blob_attr *msg)
+{
+   struct upoe *upoe = container_of(ctx, struct upoe, ubus);
+   struct device *dev = container_of(obj, struct device, ubus_obj);
+   struct blob_buf b = { };
+   //void *c;
+
+   blob_buf_init(, 0);
+
+   dev->drv->get_status(upoe, dev);
+   blobmsg_add_string(, "foo", "bar");
+
+   ubus_send_reply(ctx, req, b.head);
+
+   blob_buf_free();
+
+   return 0;
+}
+
+static const struct ubus_method upoe_ubus_device_methods[] = {
+   UBUS_METHOD_NOARG("status", upoe_device_status),
+};
+
+static struct ubus_object_type upoe_ubus_device_object_type =
+   UBUS_OBJECT_TYPE("upoe-device", upoe_ubus_device_methods);
+
+int upoe_device_register(struct upoe *upoe, struct device *dev)
+{
+struct ubus_object *obj = >ubus_obj;
+   char *name = NULL;
+   int err;
+
+   if (asprintf(, "upoe.%s", "dummy0") == -1)
+   return -ENOMEM;
+
+   obj->name = name;
+   obj->type = _ubus_device_object_type;
+   obj->methods = upoe_ubus_device_methods;
+   obj->n_methods = ARRAY_SIZE(upoe_ubus_device_methods);
+
+   err = ubus_add_object(>ubus, obj);
+   if (err) {
+   fprintf(stderr, "Failed to add ubus object\n");
+   free(name);
+   }
+
+   return err;
+}
+
+/**
+ * main()
+ **/
+
+static struct driver *drivers[] = {
+   ,
+};
+
+static int upoe_probe_devices(struct upoe *upoe) {
+   struct uci_package *p;
+   struct uci_element *e;
+
+   uci_load(upoe->uci, "upoe", );
+   if (!p) {
+   fprintf(stderr, "Failed to load upoe config\n");
+   return -ENOENT;
+   }
+
+   uci_foreach_element(>sections, e) {
+   struct uci_section *s;
+   const char *type;
+   int i;
+
+   s = uci_to_section(e);
+
+   if (strcmp(s->type, "device"))
+   continue;
+
+   type = uci_lookup_option_string(upoe->uci, s, "type");
+   if (!type)
+   continue;
+
+   for (i = 0; i < ARRAY_SIZE(drivers); i++) {
+   struct driver *drv = drivers[i];
+
+   if (!strcmp(drv->type, type)) {
+   drv->probe_device(upoe, e);
+   break;
+   }
+   }
+   }
+
+   uci_unload(upoe->uci, p);
+
+   return 0;
+}
+
+int main(int argc, char **argv) {
+   struct upoe *upoe = calloc(1, sizeof(*upoe));
+   int err;
+
+   if (!upoe) {
+   err = -ENOMEM;
+   goto err_out;
+   }

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[Rafał Miłecki]

On 11.05.2021 19:54, John Crispin wrote:

On 11.05.21 19:51, Rafał Miłecki wrote:

On 11.05.2021 19:46, John Crispin wrote:

On 11.05.21 19:45, Rafał Miłecki wrote:

I'm really tired of dealing with such hacky solutions. Look at netifd,
DSA and LuCI as example. We ended up with something that noone fully
understands. Jo - our UI guru - couldn't deal with designing a proper
UI for that f*cked config syntax. 


sorry mate, I am not the reason you are having a bad day, so dont vent it out 
on me.


It's just an example of shitty situation we got. Nothing more.

I took a good amount of time to provide valuable review for the
[PATCH v2] rtl83xx-poe: add package

I described problems, missing parts, provided examples how one can
solve it. Let's discuss that please. Instead of commenting on one
example I provided.


lulz, why so aggravated ... its about the code not the person ...

possibly I missed some of your feedback, will review tomorrow, keep the spirit 
mate and just chill a little ...


Apparently I've used too strong words, I'm sorry for that, that was
unintentional. I was trying to provide strong arguments and f*kup
example in a good faith, but as I understand it, it sounded rude.

I'd like to help adding PoE support in a clean way from the beginning,
I'll come with some ideas and maybe a code later this week. Please hold
on a bit with commiting this code, I hope we can refactor it a bit in a
reasonable time.

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

Re: [PATCH netifd] config: support bridge designed UCI section

[Hans Dedecker]

On Tue, May 11, 2021 at 7:14 PM Rafał Miłecki  wrote:
>
> From: Rafał Miłecki 
>
> Network layer 2 devices should have their own UCI section types. They
> differ so much that each device type requires a custom handling anyway.
> Currently there is "type" option used to distinguish them while UCI
> supports different section types right for that purpose. This change
> will result in cleaner UCI and UI code.
>
> Example UCI section:
>
> config bridge
> option name 'foo'
> list ports 'lan1'
> list ports 'lan2'
>
> While introducing this new bridge section a new option was added for
> storing bridge port names: "ports". It's clearer than previously used
> "ifname". A simple validation code is present to make sure "ports" is
> used and contains a list of ports.
>
> Signed-off-by: Rafał Miłecki 
Acked-by: Hans Dedecker 
> ---
>  bridge.c | 14 +-
>  config.c | 52 
>  2 files changed, 61 insertions(+), 5 deletions(-)
>
> diff --git a/bridge.c b/bridge.c
> index 099dfe4..ce49a74 100644
> --- a/bridge.c
> +++ b/bridge.c
> @@ -23,7 +23,8 @@
>  #include "system.h"
>
>  enum {
> -   BRIDGE_ATTR_IFNAME,
> +   BRIDGE_ATTR_PORTS,
> +   BRIDGE_ATTR_IFNAME, /* Deprecated */
> BRIDGE_ATTR_STP,
> BRIDGE_ATTR_FORWARD_DELAY,
> BRIDGE_ATTR_PRIORITY,
> @@ -44,6 +45,7 @@ enum {
>  };
>
>  static const struct blobmsg_policy bridge_attrs[__BRIDGE_ATTR_MAX] = {
> +   [BRIDGE_ATTR_PORTS] = { "ports", BLOBMSG_TYPE_ARRAY },
> [BRIDGE_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
> [BRIDGE_ATTR_STP] = { "stp", BLOBMSG_TYPE_BOOL },
> [BRIDGE_ATTR_FORWARD_DELAY] = { "forward_delay", BLOBMSG_TYPE_INT32 },
> @@ -104,7 +106,7 @@ struct bridge_state {
>
> struct blob_attr *config_data;
> struct bridge_config config;
> -   struct blob_attr *ifnames;
> +   struct blob_attr *ports;
> bool active;
> bool force_active;
> bool has_vlans;
> @@ -853,8 +855,8 @@ bridge_config_init(struct device *dev)
>
> bst->n_failed = 0;
> vlist_update(>members);
> -   if (bst->ifnames) {
> -   blobmsg_for_each_attr(cur, bst->ifnames, rem) {
> +   if (bst->ports) {
> +   blobmsg_for_each_attr(cur, bst->ports, rem) {
> bridge_add_member(bst, blobmsg_data(cur));
> }
> }
> @@ -970,7 +972,9 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
> if (tb_dev[DEV_ATTR_MACADDR])
> bst->primary_port = NULL;
>
> -   bst->ifnames = tb_br[BRIDGE_ATTR_IFNAME];
> +   bst->ports = tb_br[BRIDGE_ATTR_PORTS];
> +   if (!bst->ports)
> +   bst->ports = tb_br[BRIDGE_ATTR_IFNAME];
> device_init_settings(dev, tb_dev);
> bridge_apply_settings(bst, tb_br);
>
> diff --git a/config.c b/config.c
> index fa7cbe4..4cc5a61 100644
> --- a/config.c
> +++ b/config.c
> @@ -223,6 +223,57 @@ config_parse_rule(struct uci_section *s, bool v6)
> iprule_add(blob_data(b.head), v6);
>  }
>
> +/**
> + * config_init_bridges - create bridges for new syntax UCI sections
> + *
> + * The new syntax uses dedicated UCI "bridge" sections for describing 
> bridges.
> + * They use "ports" list instead of "ifname" for specifying bridge ports.
> + */
> +static void config_init_bridges()
> +{
> +   struct uci_element *e;
> +
> +   uci_foreach_element(_network->sections, e) {
> +   struct uci_section *s = uci_to_section(e);
> +   struct device_type *devtype;
> +   struct uci_option *o;
> +   struct device *dev;
> +   const char *name;
> +
> +   if (strcmp(s->type, "bridge"))
> +   continue;
> +
> +   name = uci_lookup_option_string(uci_ctx, s, "name");
> +   if (!name)
> +   continue;
> +
> +   devtype = device_type_get("bridge");
> +   if (!devtype)
> +   continue;
> +
> +   config_fixup_bridge_vlan_filtering(s, name);
> +   o = uci_lookup_option(uci_ctx, s, "ifname");
> +   if (o) {
> +   netifd_log_message(L_WARNING, "Unsupported \"ifname\" 
> bridge option\n");
> +   continue;
> +   }
> +   o = uci_lookup_option(uci_ctx, s, "ports");
> +   if (o && o->type != UCI_TYPE_LIST) {
> +   netifd_log_message(L_WARNING, "Invalid \"ports\" 
> option format\n");
> +   continue;
> +   }
> +
> +   blob_buf_init(, 0);
> +   uci_to_blob(, s, devtype->config_params);
> +
> +   dev = device_create(name, devtype, b.head);
> +   if (!dev)
> +   continue;
> +
> +   dev->default_config = false;
> +   }
> +}
> +
>  static void
>  

Re: FRAG Attacks (new vuln for wifi)

[Felix Fietkau]

On 2021-05-12 19:13, Ben Greear wrote:
> On 5/12/21 9:00 AM, Felix Fietkau wrote:
>> 
>> Hi,
>> 
>> On 2021-05-12 01:34, Paul D wrote:
>>> https://www.fragattacks.com/
>>>
>>> https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/
>> I've merged those fixes in openwrt commit 025bd93f36c9.
>> After some testing in master, we should backport them soon.
>> 
>> ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix
>> very soon. Not sure what other drivers may need fixing...
>> 
>> - Felix
>> 
> 
> Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to be 
> patched?
> Is 4.19 the oldest that owrt will consume?
I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
anything older than that.

- Felix

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

Re: FRAG Attacks (new vuln for wifi)

[Ben Greear]

On 5/12/21 9:00 AM, Felix Fietkau wrote:


Hi,

On 2021-05-12 01:34, Paul D wrote:

https://www.fragattacks.com/

https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/

I've merged those fixes in openwrt commit 025bd93f36c9.
After some testing in master, we should backport them soon.

ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix
very soon. Not sure what other drivers may need fixing...

- Felix



Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to be 
patched?
Is 4.19 the oldest that owrt will consume?

Thanks,
Ben

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

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

Re: FRAG Attacks (new vuln for wifi)

[Felix Fietkau]

Hi,

On 2021-05-12 01:34, Paul D wrote:
> https://www.fragattacks.com/
> 
> https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johan...@sipsolutions.net/
I've merged those fixes in openwrt commit 025bd93f36c9.
After some testing in master, we should backport them soon.

ath10k-ct will need to be fixed too, and I plan on pushing an mt76 fix
very soon. Not sure what other drivers may need fixing...

- Felix

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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

On 12.05.21 15:09, Bjørn Mork wrote:

Koen Vandeputte  writes:


Hi Bjørn

I can confirm the slot can also handle pcie signaling.
Got a rb912 board laying on my desk this very moment running an extra
ath9k pcie card :-)  (openwrt 19.07)

Thanks. Good to be wrong :-)


The slot is also advertised by MikroTik that it can do that.

Hmm, I could not find that.  But then again, that's probably just me
looking in the wrong places.


Bjørn



https://mikrotik.com/product/RB912UAG-5HPnD

"

The RB912UAG-5HPnD is a very versatile device.
It is a small wireless router with an integrated high power wireless 
card and an additional miniPCIe slot for 802.11 wireless, or 3G card.


"


Regards,

Koen


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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Bjørn Mork]

Koen Vandeputte  writes:

> Hi Bjørn
>
> I can confirm the slot can also handle pcie signaling.
> Got a rb912 board laying on my desk this very moment running an extra
> ath9k pcie card :-)  (openwrt 19.07)

Thanks. Good to be wrong :-)

> The slot is also advertised by MikroTik that it can do that.

Hmm, I could not find that.  But then again, that's probably just me
looking in the wrong places.


Bjørn

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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

On 12.05.21 14:47, Bjørn Mork wrote:

Koen Vandeputte  writes:


I've fixed most of the open stuff, with the exception of using a PCIe
device in the slot. (checking currently what is wrong there)

Are you sure that's supported?  This is a slot intended only for LTE
modems, isn't it?

Looking at the picture at https://i.mt.lv/cdn/rb_images/884_hi_res.png I
can't see anything connecting to the PETn0/PETp0 pair.  There are
connections to the PERn0/PERp0 pair, but the traces do not look like
they're laid out for a PCIe differential pair. I suspect that's made for
some specific modem, using those pins for a debug UART. Like the Quectel
EC25:
https://forums.quectel.com/t/issue-in-interfacing-unilec-board-with-quectel-ec-25-e-mini-pcie-card/3057/5




Bjørn


Hi Bjørn

I can confirm the slot can also handle pcie signaling.
Got a rb912 board laying on my desk this very moment running an extra 
ath9k pcie card :-)  (openwrt 19.07)


The slot is also advertised by MikroTik that it can do that.

Here is a part of a rb912 bootlog, running in the field:


[   14.008974] ath: EEPROM regdomain: 0x0
[   14.008986] ath: EEPROM indicates default country code should be used
[   14.008990] ath: doing EEPROM country->regdmn map search
[   14.009008] ath: country maps to regdmn code: 0x3a
[   14.009014] ath: Country alpha2 being used: US
[   14.009018] ath: Regpair used: 0x3a
[   14.025334] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   14.027550] ieee80211 phy0: Atheros AR9340 Rev:3 mem=0xb810, irq=47

[   14.034690] pci :00:00.0: using irq 40 for pin 1
[   14.039934] PCI: Enabling device :00:00.0 ( -> 0002)
[   14.054898] ath: EEPROM regdomain: 0x0
[   14.054906] ath: EEPROM indicates default country code should be used
[   14.054910] ath: doing EEPROM country->regdmn map search
[   14.054928] ath: country maps to regdmn code: 0x3a
[   14.054935] ath: Country alpha2 being used: US
[   14.054939] ath: Regpair used: 0x3a
[   14.068383] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   14.070596] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0xb000, irq=40


Regards,

Koen


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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Bjørn Mork]

Koen Vandeputte  writes:

> I've fixed most of the open stuff, with the exception of using a PCIe
> device in the slot. (checking currently what is wrong there)

Are you sure that's supported?  This is a slot intended only for LTE
modems, isn't it?

Looking at the picture at https://i.mt.lv/cdn/rb_images/884_hi_res.png I
can't see anything connecting to the PETn0/PETp0 pair.  There are
connections to the PERn0/PERp0 pair, but the traces do not look like
they're laid out for a PCIe differential pair. I suspect that's made for
some specific modem, using those pins for a debug UART. Like the Quectel
EC25:
https://forums.quectel.com/t/issue-in-interfacing-unilec-board-with-quectel-ec-25-e-mini-pcie-card/3057/5




Bjørn

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

ZTE ZXV10-H201L

[Slobodan]

Hey guys,

Im trying to put OpenWrt on my ZTE ZXV10-H201L and after flashing image
without vmmc driver device boot's but without WiFi
Here is little log trying to reset WiFi

root@OpenWrt 
:/sys/devices/platform/1000.fpi/1e100b10.pinmux/gpiochip0/gpio/wifi# 


echo 0 > value
root@OpenWrt 
:/sys/devices/platform/1000.fpi/1e100b10.pinmux/gpiochip0/gpio/wifi# 


echo 1 > value
[ 310.050982] usb 1-1: new high-speed USB device number 3 using dwc2
[ 310.265365] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw
requested
[ 310.564695] usb 1-1: ath9k_htc: Transferred FW:
ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[ 310.816790] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits
[ 311.243039] ath: phy1: Failed to read SREV register
[ 311.243061] ath: phy1: Could not read hardware revisions
[ 311.246562] ath: phy1: Unable to initialize hardware; initialization
status: -122
[ 311.259311] ath: phy1: Unable to initialize hardware; initialization
status: -122
[ 311.273171] ath9k_htc: Failed to initialize the device
[ 311.277527] usb 1-1: ath9k_htc: USB layer deinitialized

So does anyone have and idea what should I try ?

Best regards Slobodan

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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

Hi Denis,

I have high interest in this target device and wanted to provide some 
assistance if that's ok with you.
I've fixed most of the open stuff, with the exception of using a PCIe 
device in the slot. (checking currently what is wrong there)


Changes:
- dts cleanup
- Enabled USB
- Added required GPIO's for USB switching functionality (Type-A vs mini 
pcie slot)

- Added pcie device power gpio (default ON)
- Added kernel 5.10 support
- use maximum SPI speed compatible with any type/brand of EEPROM (Dual & 
Quad)

- use maximum SPI speed compatbile with any type/brand of SSR chip
- added beeper package

I also have different hw revisions of this board.
- Oldest revision: works as expected, also when booting from flash
- Newer revision: ethernet works when booting from ethernet, but not 
when booted from flash (interface is up, IP is set, but not able to ping 
it.)


I also have a board running latest RouterOS on it.
It seems it should be possible to also fetch Voltage and Temperature 
somewhere.


Do you have an update?

Thanks,
Kind regards,

Koen

On 06.05.21 18:35, John Crispin wrote:
interesting. I have a rb92xx on my desk and am wondering if this would 
also work ? after a brief glance at the code I think this might work. 
the rb92xx certainly has the same latch setup ...


    John

On 06.05.21 18:19, 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).

Denis Kalashnikov (4):
   ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
   ath79: add GPIO-latch driver for Mikrotik RB91xG
   ath79: add NAND driver for Mikrotik RB91xG
   ath79: add support of Mikrotik RouterBoard 91xG series

  .../dts/ar9342_mikrotik_routerboard-912g.dts  | 314 +
  .../files/drivers/gpio/gpio-latch-rb91x.c | 127 +
  .../linux/ath79/files/drivers/mfd/rb91x-ngl.c | 331 ++
  .../files/drivers/mtd/nand/raw/nand_rb91x.c   | 432 ++
  .../linux/ath79/files/include/mfd/rb91x-ngl.h |  59 +++
  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    |   3 +
  .../patches-5.4/939-mikrotik-rb91x.patch  |  65 +++
  11 files changed, 1344 insertions(+)
  create mode 100644 
target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
  create mode 100644 
target/linux/ath79/files/drivers/gpio/gpio-latch-rb91x.c

  create mode 100644 target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
  create mode 100644 
target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.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




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


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

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[Petr Štetiar]

John Crispin  [2021-05-11 19:43:09]:

> that being said, I have a edgerouter-x(-sfp) on my desk. I already started a
> PoC patch to support a more generic approach for PoE that is agnostic of
> wheter the HW support is driven via GPIO or a ttyS attached MCU.

Then you should consider renaming it to something generic as well, upoe(d) or
such.

-- ynezz

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

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[Petr Štetiar]

John Crispin  [2021-05-11 17:22:43]:

Hi,

>  package/network/config/realtek-poe/src/main.c | 844 ++

I would prefer to have this as out of tree project, so we could add CI
pipeline to it for improved QA.

> +struct port_config {
> + char name[16];

It would be nice to get rid of all those magic numbers as well, there is a lot
of them.

Ideally the command bytes offsets should be defined (via some enum?) as well,
so it's easier to review the code otherwise one would need to keep in head,
that byte 11 is CRC etc.

> + fprintf(stderr, "%s ->", type);
> + for (i = 0; i < 12; i++)
> + fprintf(stderr, " 0x%02x", data[i]);
> + fprintf(stderr, "\n");

ULOG_DBG ?

> + config.port_count = reply[3];

this should be checked for > MAX_PORT

> + state.ports[reply[2]].poe_mode = GET_STR(reply[3], mode);

reply[2] should be checked for > MAX_PORT

> + for (i = 0; i < 8; i++)

i < MAX_PORT

> + state.ports[reply[2]].watt = watt;

reply[2] should be checked for > MAX_PORT

> + if (ret)
> + fprintf(stderr, "Failed to add object: %s\n", 
> ubus_strerror(ret));

ULOG_ERR ?

-- ynezz

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