[OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Mathias [0] https://github.com/openwrt/openwrt/pull/1577 [1] https://openwrt.org/supported_devices/432_warning ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
05/12/2018 09:56, Mathias Kresin: Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Mathias [0] https://github.com/openwrt/openwrt/pull/1577 [1] https://openwrt.org/supported_devices/432_warning I wasn't that clear in my mail. I would like to stop accepting patches for boards with only 32 MByte of RAM _OR_ 4 MByte of flash. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
As a frequent user of openwrt, and app developer for openwrt, I definitely agree to stop patches for these devices with very low resources. Better to invest available development efforts on reasonable devices, having 64MB RAM, 8MB flash, minimum. Cheers, Reiner Am 05.12.2018 um 11:07 schrieb Mathias Kresin: 05/12/2018 09:56, Mathias Kresin: Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Mathias [0] https://github.com/openwrt/openwrt/pull/1577 [1] https://openwrt.org/supported_devices/432_warning I wasn't that clear in my mail. I would like to stop accepting patches for boards with only 32 MByte of RAM _OR_ 4 MByte of flash. Mathias ___ 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: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
Em 04/12/2018 19:57, Piotr Dymacz escreveu: On 04.12.2018 17:08, Henrique de Moraes Holschuh wrote: Another aspect was the LED configuration, as LED naming is very inconsistent and often differs from ar71xx. Some LEDs are now not included in UCI configuration. > So you either need to delete (and recreate) them ore just dump your '/etc/config/system' and recreate it using "config_generate". Is it possible to have uci-defaults/ to fix those on upgrade (i.e. when it detects ar71xx-style traces in the system)? As well as the wmac path? Because a _lot_ of people will need to do ar71xx->ath79. ar71xx already includes such "migration" uci-defaults scripts and I believe we could use something similar in ath79 to make the update transparent for users (fix wmac path, LED names etc.). LED example: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration Yes, that's exactly what I meant... In ath79's case, it makes sense to handle not only changes in the ath79 DTSes (ath79->ath79), but also migrations from ar71xx (ar71xx->ath79), even if we create a specific config option to handle that (to compile it out from small flash devices, for example). Do we have a wiki table somewhere that has the device name, ar71xx info and ath79 info, which could be expanded with ar71xx->ath79 status (no, yes but unverified, yes verified to be complete)? That would be really useful to direct efforts on adding ath79 support to something that is still ar71xx-only, as well as adding ar71xx->ath79 support to targets of interest (i.e. those one happens to know what changes are required for the migration, really). I suppose one would also add any remarks about ath79 support being incomplete or any regressions for each target one knows about, too. That would help steering the ar71xx deprecation. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools] blockd: don't unmount device when removing it from the list
> Op 4 dec. 2018, om 12:32 heeft Rafał Miłecki het volgende
> geschreven:
>
> From: Rafał Miłecki
>
> Device gets removed from the list (vlist_delete()) when block calls
> "hotplug" method of blockd using ubus. Right after that block unmounts
> that device on its own.
>
> blockd shouldn't care about unmounting on its own for following reasons:
> 1) To avoid code/behavior duplication with block
> 2) To keep behavior consistent with mounting (blockd doesn't mount)
> 3) To allow implementing more features in block (e.g. hotplug.d events)
>
> The design should be to:
> 1) Have block handle (un)mounting
> 2) Use blockd for providing devices/mounts state (using ubus)
> 3) Have blockd handle autofs and call block when needed
Can this cause a transition into a state where a device is (still) mounted but
removed from the list, and if so, is that a valid, an admissible state ?
Shouldn't block be required to first unmount before calling blockd's hotplug
entry ?
>
> Signed-off-by: Rafał Miłecki
> ---
> blockd.c | 26 ++
> 1 file changed, 2 insertions(+), 24 deletions(-)
>
> diff --git a/blockd.c b/blockd.c
> index a5da32c..1379635 100644
> --- a/blockd.c
> +++ b/blockd.c
> @@ -112,34 +112,12 @@ static void
> device_free(struct device *device)
> {
> struct blob_attr *data[__MOUNT_MAX];
> - char *target = NULL;
> - char *path = NULL, _path[64], *mp;
>
> blobmsg_parse(mount_policy, __MOUNT_MAX, data,
> blob_data(device->msg), blob_len(device->msg));
>
> - if (data[MOUNT_AUTOFS]) {
> - target = device->target;
> - snprintf(_path, sizeof(_path), "/tmp/run/blockd/%s",
> - blobmsg_get_string(data[MOUNT_DEVICE]));
> - path = _path;
> - } else {
> - path = target = device->target;
> - }
> -
> - mp = _find_mount_point(device->name);
> - if (path && mp)
> - if (umount2(path, MNT_DETACH))
> - ULOG_ERR("failed to unmount %s\n", path);
> - free(mp);
> -
> - if (!target)
> - return;
> -
> - if (data[MOUNT_AUTOFS])
> - unlink(target);
> - else
> - rmdir(target);
> + if (data[MOUNT_AUTOFS] && device->target)
> + unlink(device->target);
> }
>
> static void
> --
> 2.13.7
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Paul Oranje
M +31 6 2127 8389
T +31 20 494 1306
Achterlaan 20, 1027 AK Zunderdorp
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools] blockd: don't unmount device when removing it from the list
On 2018-12-05 13:31, Paul Oranje wrote: Op 4 dec. 2018, om 12:32 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Device gets removed from the list (vlist_delete()) when block calls "hotplug" method of blockd using ubus. Right after that block unmounts that device on its own. blockd shouldn't care about unmounting on its own for following reasons: 1) To avoid code/behavior duplication with blockThe chicken or the eggThe chicken or the egg 2) To keep behavior consistent with mounting (blockd doesn't mount) 3) To allow implementing more features in block (e.g. hotplug.d events) The design should be to: 1) Have block handle (un)mounting 2) Use blockd for providing devices/mounts state (using ubus) 3) Have blockd handle autofs and call block when needed Can this cause a transition into a state where a device is (still) mounted but removed from the list, and if so, is that a valid, an admissible state ? Shouldn't block be required to first unmount before calling blockd's hotplug entry ? The chicken or the egg? ;) We don't have any mutex/semaphore mechanism in place right now. So unless that gets implemented, we have to chooce what's better. I believe the correct order would be to: 1) Stop reporting mounted device 2) Notify all users about unmounting (hotplug.d event I work on) 3) Unmount That's the safest way that will stop applications from trying to access device due to blockd incorrectly reporting it as mounted. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Mathias Kresin [2018-12-05 10:07:52]: Hi, > > IMHO it doesn't make much sense to waste resources (reviewer time, build > > resources) for boards which will most likely never see an official build > > and/or are more or less unusable with the official build. I fully agree on dropping support for devices with 4M of flash memory. > I wasn't that clear in my mail. I would like to stop accepting patches for > boards with only 32 MByte of RAM _OR_ 4 MByte of flash. Althought I personaly don't own 8/32M device, I can very well imagine, that OpenWrt without LuCi is still somehow usable on such devices, so I'm wondering what it would mean to retain support for such devices - maintainer(s) willing to spend time on this devices, adding corresponding tiny targets? Would it be possible to get some download stats for release/snapshot images, so we can get some rough numbers about popularity of devices in the wild? -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
I was about to recommend the Download Stats page at https://downloads.openwrt.org/stats/ as a first cut... > Would it be possible to get some download stats for release/snapshot images, > so we can get some rough numbers about popularity of devices in the wild? BUT... that page doesn't seem to be collecting any stats since 21 Nov 2018. OpenWrt Admin's are cc'd on this note. Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
I still have a bunch of Old Foneras and some TP-Link 703N and TL-MR11U battery powered micro-routers. The foneras are kinda useless, but the TP-Links are somewhat usefull and I still use them with OpenWRT. What other inexpensive routers would you sugest to substitute the ones from TP-Link I just cited? On Wed, 5 Dec 2018 at 14:02, Rich Brown wrote: > > I was about to recommend the Download Stats page at > https://downloads.openwrt.org/stats/ as a first cut... > > > Would it be possible to get some download stats for release/snapshot images, > > so we can get some rough numbers about popularity of devices in the wild? > > BUT... that page doesn't seem to be collecting any stats since 21 Nov 2018. > OpenWrt Admin's are cc'd on this note. > > Rich > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Please don't top post and keep all lists as recipients. I added openwrt-devel back to the list of recipients. 05/12/2018 14:57, Fernando Frediani: Hi Just to make it clear you mean that for the master right ? Not for 18.06 (when it becomes 19.0x) and LEDE 17.01 (while it's still alive) ? If so I agree 4MB isn't something much feasible anymore. You got my mail wrong. It is about not accepting new patches for such boards. Dropping support for existing boards wasn't mentioned and isn't my intention. Btw. master will be 19.0x. Mathias However for 32MB devices I have serious doubts as mentioned in another email there are good devices that may work well with 32MB/8MB and I don't think hardly dropping it is a good idea, at least not for the current 18.06. And I am still seeing that some new devices are going to marketed with 32MB/8MB so 64MB RAM ones are not majority yet. Do you have any numbers of how much effort will be put into that to perhaps justify this hard drop for 32MB ones and mainly about the popularity of these devices from the download website ? I am not sure a vote would be the best thing to use in this scenario, otherwise there would need to be a vote for other things discussed and not always that is something ends well. Let's see how this thread goes before considering it. Regards Fernando On 05/12/2018 06:56, Mathias Kresin wrote: Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Mathias [0] https://github.com/openwrt/openwrt/pull/1577 [1] https://openwrt.org/supported_devices/432_warning ___ openwrt-adm mailing list openwrt-...@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-adm ___ openwrt-adm mailing list openwrt-...@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-adm ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Sorry about that. I had clicked into Reply to List and for some reason it included only one of them. Then the question may be simpler only about 32MB of RAM if it's the case for newer devices or not. Let's see others opinions. I am not entirely convinced but I see your point. Fernando On 05/12/2018 12:18, Mathias Kresin wrote: Please don't top post and keep all lists as recipients. I added openwrt-devel back to the list of recipients. 05/12/2018 14:57, Fernando Frediani: Hi Just to make it clear you mean that for the master right ? Not for 18.06 (when it becomes 19.0x) and LEDE 17.01 (while it's still alive) ? If so I agree 4MB isn't something much feasible anymore. You got my mail wrong. It is about not accepting new patches for such boards. Dropping support for existing boards wasn't mentioned and isn't my intention. Btw. master will be 19.0x. Mathias However for 32MB devices I have serious doubts as mentioned in another email there are good devices that may work well with 32MB/8MB and I don't think hardly dropping it is a good idea, at least not for the current 18.06. And I am still seeing that some new devices are going to marketed with 32MB/8MB so 64MB RAM ones are not majority yet. Do you have any numbers of how much effort will be put into that to perhaps justify this hard drop for 32MB ones and mainly about the popularity of these devices from the download website ? I am not sure a vote would be the best thing to use in this scenario, otherwise there would need to be a vote for other things discussed and not always that is something ends well. Let's see how this thread goes before considering it. Regards Fernando On 05/12/2018 06:56, Mathias Kresin wrote: Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Mathias [0] https://github.com/openwrt/openwrt/pull/1577 [1] https://openwrt.org/supported_devices/432_warning ___ openwrt-adm mailing list openwrt-...@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-adm ___ openwrt-adm mailing list openwrt-...@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-adm ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] kernel: ar83xx: Add support for three GMAC's connection
We have IPQ8064 AP161 board which has three GMAC's
* RGMII x2
* SGMII x1.
The existing ar8327 driver does not have support for
three GMAC's connection, hence this change adds support
for the same. This has been verified on AP148 and AP161
board.
Signed-off-by: xiaofeis
Signed-off-by: Ram Chandra Jangir
---
Changes since v1:
* Added RGMII properties as bool
.../linux/generic/files/drivers/net/phy/ar8216.c | 15 +++-
.../linux/generic/files/drivers/net/phy/ar8216.h | 4 ++
.../linux/generic/files/drivers/net/phy/ar8327.c | 44 ++
.../linux/generic/files/drivers/net/phy/ar8327.h | 7
4 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index 68754e6..2f0be1b 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -295,6 +295,17 @@ ar8xxx_rmw(struct ar8xxx_priv *priv, int reg, u32 mask,
u32 val)
return ret;
}
+void
+ar8xxx_phy_dbg_read(struct ar8xxx_priv *priv, int phy_addr,
+ u16 dbg_addr, u16 *dbg_data)
+{
+ struct mii_bus *bus = priv->mii_bus;
+
+ mutex_lock(&bus->mdio_lock);
+ bus->write(bus, phy_addr, MII_ATH_DBG_ADDR, dbg_addr);
+ *dbg_data = bus->read(bus, phy_addr, MII_ATH_DBG_DATA);
+ mutex_unlock(&bus->mdio_lock);
+}
void
ar8xxx_phy_dbg_write(struct ar8xxx_priv *priv, int phy_addr,
@@ -2166,7 +2177,7 @@ ar8xxx_phy_probe(struct phy_device *phydev)
int ret;
/* skip PHYs at unused adresses */
- if (phydev->mdio.addr != 0 && phydev->mdio.addr != 4)
+ if (phydev->mdio.addr != 0 && phydev->mdio.addr != 3 &&
phydev->mdio.addr != 4)
return -ENODEV;
if (!ar8xxx_is_possible(phydev->mdio.bus))
@@ -2225,6 +2236,8 @@ found:
phydev->supported |= SUPPORTED_1000baseT_Full;
phydev->advertising |= ADVERTISED_1000baseT_Full;
}
+ if (priv->chip->phy_rgmii_set)
+ priv->chip->phy_rgmii_set(priv, phydev);
}
phydev->priv = priv;
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h
b/target/linux/generic/files/drivers/net/phy/ar8216.h
index 509818c..33f505c 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.h
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.h
@@ -413,6 +413,7 @@ struct ar8xxx_chip {
void (*get_arl_entry)(struct ar8xxx_priv *priv, struct arl_entry *a,
u32 *status, enum arl_op op);
int (*sw_hw_apply)(struct switch_dev *dev);
+ void (*phy_rgmii_set)(struct ar8xxx_priv *priv, struct phy_device
*phydev);
const struct ar8xxx_mib_desc *mib_decs;
unsigned num_mibs;
@@ -478,6 +479,9 @@ u32
ar8xxx_rmw(struct ar8xxx_priv *priv, int reg, u32 mask, u32 val);
void
+ar8xxx_phy_dbg_read(struct ar8xxx_priv *priv, int phy_addr,
+ u16 dbg_addr, u16 *dbg_data);
+void
ar8xxx_phy_dbg_write(struct ar8xxx_priv *priv, int phy_addr,
u16 dbg_addr, u16 dbg_data);
void
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 803fb3d..170c3e4 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -128,6 +128,49 @@ ar8327_get_pad_cfg(struct ar8327_pad_cfg *cfg)
}
static void
+ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct phy_device *phydev)
+{
+ u16 phy_val = 0;
+ int phyaddr = phydev->mdio.addr;
+ struct device_node *np = phydev->mdio.dev.of_node;
+
+ if (!np)
+ return;
+
+ if (!of_property_read_bool(np, "qca,phy-rgmii-en")) {
+ pr_err("ar8327: qca,phy-rgmii-en is not specified\n");
+ return -EINVAL;
+ }
+ ar8xxx_phy_dbg_read(priv, phyaddr,
+ AR8327_PHY_MODE_SEL, &phy_val);
+ phy_val |= AR8327_PHY_MODE_SEL_RGMII;
+ ar8xxx_phy_dbg_write(priv, phyaddr,
+ AR8327_PHY_MODE_SEL, phy_val);
+
+ /* set rgmii tx clock delay if needed */
+ if (!of_property_read_bool(np, "qca,txclk-delay-en")) {
+ pr_err("ar8327: qca,txclk-delay-en is not specified\n");
+ return -EINVAL;
+ }
+ ar8xxx_phy_dbg_read(priv, phyaddr,
+ AR8327_PHY_SYS_CTRL, &phy_val);
+ phy_val |= AR8327_PHY_SYS_CTRL_RGMII_TX_DELAY;
+ ar8xxx_phy_dbg_write(priv, phyaddr,
+ AR8327_PHY_SYS_CTRL, phy_val);
+
+ /* set rgmii rx clock delay if needed */
+ if (!of_property_read_bool(np, "qca,rxclk-delay-en")) {
+ pr_err("ar8327: qca,rxclk-delay-en is not specified\n");
+ return -EINVAL;
+ }
+ ar8xxx_phy_dbg_read(priv, phyaddr
[OpenWrt-Devel] [PATCH v2 2/2] ipq806x: dts: Add support for RGMII RX and TX clock delays
This change enables support to select phy4 in RGMII mode and
enables RGMII TX/RX clock internal delays.
Signed-off-by: Ram Chandra Jangir
---
.../linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-ap161.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
index 8c5a4fe..7e589be 100644
--- a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
+++ b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
@@ -220,6 +220,9 @@
phy4: ethernet-phy@4 {
reg = <4>;
+ qca,phy-rgmii-en;
+ qca,txclk-delay-en;
+ qca,rxclk-delay-en;
};
phy3: ethernet-phy@3 {
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
On 05/12/2018 14:08, Carlos Ferreira wrote: > I still have a bunch of Old Foneras and some TP-Link 703N and TL-MR11U > battery powered micro-routers. > The foneras are kinda useless, but the TP-Links are somewhat usefull > and I still use them with OpenWRT. > > What other inexpensive routers would you sugest to substitute the ones > from TP-Link I just cited? I don't know about battery powered, but the WR703N is handily replaced by the likes of the GL.iNet MT300N-V2, AR150, AR300M. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
On 05/12/2018 15:08, Carlos Ferreira wrote: I still have a bunch of Old Foneras and some TP-Link 703N and TL-MR11U battery powered micro-routers. The foneras are kinda useless, but the TP-Links are somewhat usefull and I still use them with OpenWRT. What other inexpensive routers would you sugest to substitute the ones from TP-Link I just cited? I'll recommend GL.inet minirouters, AR150 (which is basically the same SoC but with 16MB flash and 64MB ram) or MT300N, AR300M lite. Can be found for 20$ or less and are all straight upgrades over the 703N while keeping the same size, more ram/rom/ethernet ports, SD card slots and PoE modules in some cases. Their battery-powered minirouter has a mini pcie slot for a 4G modem, but it's not inexpensive. It's around 60$ without the modem (or more with a 4G modem installed) It's the GL-MiFi. They use OpenWrt as base firmware, and have web interface in uboot for firmware recovery. https://www.gl-inet.com/ -Alberto On Wed, 5 Dec 2018 at 14:02, Rich Brown wrote: I was about to recommend the Download Stats page at https://downloads.openwrt.org/stats/ as a first cut... Would it be possible to get some download stats for release/snapshot images, so we can get some rough numbers about popularity of devices in the wild? BUT... that page doesn't seem to be collecting any stats since 21 Nov 2018. OpenWrt Admin's are cc'd on this note. Rich ___ 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: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
@Alex Maclean and @Alberto Bursi Thank you for the recomendations! On Wed, 5 Dec 2018 at 14:39, Alberto Bursi wrote: > > > On 05/12/2018 15:08, Carlos Ferreira wrote: > > I still have a bunch of Old Foneras and some TP-Link 703N and TL-MR11U > > battery powered micro-routers. > > The foneras are kinda useless, but the TP-Links are somewhat usefull > > and I still use them with OpenWRT. > > > > What other inexpensive routers would you sugest to substitute the ones > > from TP-Link I just cited? > > I'll recommend GL.inet minirouters, AR150 (which is basically the same > SoC but with 16MB flash and 64MB ram) or MT300N, AR300M lite. Can be > found for 20$ or less and are all straight upgrades over the 703N while > keeping the same size, more ram/rom/ethernet ports, SD card slots and > PoE modules in some cases. > > Their battery-powered minirouter has a mini pcie slot for a 4G modem, > but it's not inexpensive. It's around 60$ without the modem (or more > with a 4G modem installed) It's the GL-MiFi. > > They use OpenWrt as base firmware, and have web interface in uboot for > firmware recovery. > > https://www.gl-inet.com/ > > -Alberto > > > On Wed, 5 Dec 2018 at 14:02, Rich Brown wrote: > >> I was about to recommend the Download Stats page at > >> https://downloads.openwrt.org/stats/ as a first cut... > >> > >>> Would it be possible to get some download stats for release/snapshot > >>> images, > >>> so we can get some rough numbers about popularity of devices in the wild? > >> BUT... that page doesn't seem to be collecting any stats since 21 Nov > >> 2018. OpenWrt Admin's are cc'd on this note. > >> > >> Rich > >> ___ > >> 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 -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi Mathias, On 05.12.2018 09:56, Mathias Kresin wrote: Hey all, I would like to start to reject patches for adding boards with only 32 MByte of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt default builds and require quite some modifications to be useful at all [1]. In general I agree but I still consider OpenWrt more like a platform than a ready Linux distribution. For me this means that even if snapshot or release images are missing for some devices because of their limited resources, thanks to keeping basic support for them in code base, users are still able to make use of them. There are already devices in repo which didn't get official image for 18.06 release but now have snapshot images and can be even more useful with a custom/self made image. IMHO it doesn't make much sense to waste resources (reviewer time, build resources) for boards which will most likely never see an official build and/or are more or less unusable with the official build. In case of DTS based targets (where single device support in code doesn't have that big impact like in, for example, ar71xx) and good quality patch/PR I don't see a reason to not merge the support. And in case the official snapshot/release build can't fit in available flash space and we are really worried about build resources, we can just disable image generation for the device. This way, users and downstream projects would be still able to make use of OpenWrt on resource-limited devices without the need to maintain custom device support patches. I prefer to have a joint statement which I can link to, to prevent endless discussions or accusations of acting purely arbitrary. Instead of making this a strict rule now I would prefer to leave final decision to the developer who takes care of patch/PR _and_ establish a clear dead line for this to become a strict rule. Lets say: after 19.06 release we no longer accept support patches for devices with only 4 MB of flash or 32 MB of RAM. I'm not sure whether the topic qualifies for a formal voting, hence the RFC. Thanks for bringing up this topic. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Mathias Kresin wrote: > I would like to start to reject patches for adding boards with only 32 MByte > of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt > default builds and require quite some modifications to be useful at all > [1]. So, no new boards that have <4M flash, or <32M ram, or no patches providing fixes for existing targets that are at that level? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] block: generate hotplug.d mount events
From: Rafał Miłecki
This is what was implemented in mountd and what some scripts used to
use. It's a pretty generic solution for managing software that may use
e.g. USB storage.
Signed-off-by: Rafał Miłecki
---
block.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/block.c b/block.c
index 46050b4..fe63fb0 100644
--- a/block.c
+++ b/block.c
@@ -880,6 +880,31 @@ static int exec_mount(const char *source, const char
*target,
return err;
}
+static void hotplug_call_mount(const char *action, const char *device)
+{
+ pid_t pid;
+
+ pid = fork();
+ if (!pid) {
+ char * const argv[] = { "hotplug-call", "mount", NULL };
+ char actionenv[] = "ACTION=xx";
+ char deviceenv[32];
+ char *envp[] = { actionenv, deviceenv, NULL };
+
+ snprintf(actionenv, sizeof(actionenv), "ACTION=%s", action);
+ snprintf(deviceenv, sizeof(deviceenv), "DEVICE=%s", device);
+
+ execve("/sbin/hotplug-call", argv, envp);
+ exit(-1);
+ } else if (pid > 0) {
+ int status;
+
+ waitpid(pid, &status, 0);
+ if (WEXITSTATUS(status))
+ ULOG_ERR("hotplug-call call failed: %d\n",
WEXITSTATUS(status));
+ }
+}
+
static int handle_mount(const char *source, const char *target,
const char *fstype, struct mount *m)
{
@@ -1079,6 +1104,8 @@ static int mount_device(struct probe_info *pr, int type)
handle_swapfiles(true);
+ hotplug_call_mount("add", device);
+
return 0;
}
@@ -1091,6 +1118,8 @@ static int umount_device(char *path)
if (!mp)
return -1;
+ hotplug_call_mount("remove", basename(path));
+
err = umount2(mp, MNT_DETACH);
if (err)
ULOG_ERR("unmounting %s (%s) failed (%d) - %m\n", path, mp,
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] block: generate hotplug.d mount events
On 2018-12-05 22:35, Rafał Miłecki wrote: From: Rafał Miłecki This is what was implemented in mountd and what some scripts used to use. It's a pretty generic solution for managing software that may use e.g. USB storage. Signed-off-by: Rafał Miłecki Forgot to say, it requires [PATCH fstools] blockd: don't unmount device when removing it from the list to work correctly. Without above patch blockd unmounts device, block can't find a mount point and gives up. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] block: generate hotplug.d mount events
On 05/12/18 22:35, Rafał Miłecki wrote:
From: Rafał Miłecki
This is what was implemented in mountd and what some scripts used to
use. It's a pretty generic solution for managing software that may use
e.g. USB storage.
Could you explain a bit more about what is this doing instead of just
mentioning mountd?
There is pretty scarce info about mountd.
-Alberto
Signed-off-by: Rafał Miłecki
---
block.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/block.c b/block.c
index 46050b4..fe63fb0 100644
--- a/block.c
+++ b/block.c
@@ -880,6 +880,31 @@ static int exec_mount(const char *source, const char
*target,
return err;
}
+static void hotplug_call_mount(const char *action, const char *device)
+{
+ pid_t pid;
+
+ pid = fork();
+ if (!pid) {
+ char * const argv[] = { "hotplug-call", "mount", NULL };
+ char actionenv[] = "ACTION=xx";
+ char deviceenv[32];
+ char *envp[] = { actionenv, deviceenv, NULL };
+
+ snprintf(actionenv, sizeof(actionenv), "ACTION=%s", action);
+ snprintf(deviceenv, sizeof(deviceenv), "DEVICE=%s", device);
+
+ execve("/sbin/hotplug-call", argv, envp);
+ exit(-1);
+ } else if (pid > 0) {
+ int status;
+
+ waitpid(pid, &status, 0);
+ if (WEXITSTATUS(status))
+ ULOG_ERR("hotplug-call call failed: %d\n",
WEXITSTATUS(status));
+ }
+}
+
static int handle_mount(const char *source, const char *target,
const char *fstype, struct mount *m)
{
@@ -1079,6 +1104,8 @@ static int mount_device(struct probe_info *pr, int type)
handle_swapfiles(true);
+ hotplug_call_mount("add", device);
+
return 0;
}
@@ -1091,6 +1118,8 @@ static int umount_device(char *path)
if (!mp)
return -1;
+ hotplug_call_mount("remove", basename(path));
+
err = umount2(mp, MNT_DETACH);
if (err)
ULOG_ERR("unmounting %s (%s) failed (%d) - %m\n", path, mp,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] procd: simplify code in procd_inittab_run
This is a trial to make it more obvious what the historically
grown code is actually doing.
Signed-off-by: Michael Heimpold
---
inittab.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/inittab.c b/inittab.c
index 4b9..41816b7 100644
--- a/inittab.c
+++ b/inittab.c
@@ -259,12 +259,11 @@ void procd_inittab_run(const char *handler)
list_for_each_entry(a, &actions, list)
if (!strcmp(a->handler->name, handler)) {
- if (a->handler->multi) {
- a->handler->cb(a);
- continue;
- }
a->handler->cb(a);
- break;
+ if (a->handler->multi)
+ continue;
+ else
+ break;
}
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
> -Ursprüngliche Nachricht- > Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im > Auftrag von Henrique de Moraes Holschuh > Gesendet: Mittwoch, 5. Dezember 2018 11:03 [...] > Do we have a wiki table somewhere that has the device name, ar71xx info > and ath79 info, which could be expanded with ar71xx->ath79 status (no, > yes but unverified, yes verified to be complete)? > > That would be really useful to direct efforts on adding ath79 support > to something that is still ar71xx-only, as well as adding ar71xx->ath79 > support to targets of interest (i.e. those one happens to know what > changes are required for the migration, really). > > I suppose one would also add any remarks about ath79 support being > incomplete or any regressions for each target one knows about, too. > That would help steering the ar71xx deprecation. There is a table that documents the ath79 status in the OpenWrt forum: https://forum.openwrt.org/t/ath79-target-status/18614/9 The place to put this into the wiki would be: https://openwrt.org/docs/techref/targets/ath79 We can define a new target "ar71xx-ath79" for the dataentries, which would then give us these 3 options: 1) "ar71xx" # device is ar71xx only 2) "ath79" # device is ath79 only 3) "ar71xx-ath79"# device is migrated (and working, if nothing in "Unsupported Functions") ---> devices will automatically show up on the ath79 and/or ar71xx wikipage (slight modifications necessary). For "ath79 WIP" devices, we can set the "Unsupported Functions" datafield (that's where WIP usually is found) to "ath79 WIP, see forum". Any detailed discussion or description of incomplete support should happen elsewhere, i.e. either in the forum or on the respective devicepages. Please let me know if this meets your requirements. Thomas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] comgt: Fix 3g.sh permissions
3g.sh needs to be executable. 600 is not correct for that. Signed-off-by: Rosen Penev --- package/network/utils/comgt/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/utils/comgt/Makefile b/package/network/utils/comgt/Makefile index d4d673e783..58466f498c 100644 --- a/package/network/utils/comgt/Makefile +++ b/package/network/utils/comgt/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=comgt PKG_VERSION:=0.32 -PKG_RELEASE:=31 +PKG_RELEASE:=32 PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz PKG_SOURCE_URL:=@SF/comgt @@ -82,7 +82,7 @@ define Package/comgt/install $(INSTALL_DIR) $(1)/etc/hotplug.d/tty $(INSTALL_CONF) ./files/3g.usb $(1)/etc/hotplug.d/tty/30-3g $(INSTALL_DIR) $(1)/lib/netifd/proto - $(INSTALL_CONF) ./files/3g.sh $(1)/lib/netifd/proto/3g.sh + $(INSTALL_BIN) ./files/3g.sh $(1)/lib/netifd/proto/3g.sh endef define Package/comgt-directip/install -- 2.17.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] block: generate hotplug.d mount events
On Wed, 5 Dec 2018 at 23:30, Alberto Bursi wrote: > On 05/12/18 22:35, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > This is what was implemented in mountd and what some scripts used to > > use. It's a pretty generic solution for managing software that may use > > e.g. USB storage. > > > Could you explain a bit more about what is this doing instead of just > mentioning mountd? > > There is pretty scarce info about mountd. This generates following hotplug.d "mount" events: 1) "add" when block device gets mounted 2) "remove" when block device gets unmounted It allows one to put custom scripts/executables in the /etc/hotplug.d/mount/ and react to appearing/disappearing mount points. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: simplify code in procd_inittab_run
Hi,
> This is a trial to make it more obvious what the historically
> grown code is actually doing.
when we already refactor the code...
> Signed-off-by: Michael Heimpold
> ---
> inittab.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/inittab.c b/inittab.c
> index 4b9..41816b7 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -259,12 +259,11 @@ void procd_inittab_run(const char *handler)
>
> list_for_each_entry(a, &actions, list)
> if (!strcmp(a->handler->name, handler)) {
> - if (a->handler->multi) {
> - a->handler->cb(a);
> - continue;
> - }
> a->handler->cb(a);
> - break;
> + if (a->handler->multi)
> + continue;
> + else
> + break;
... why not just change this to:
if (!a->handler->multi)
break;
> }
> }
>
>
Regards,
Jo
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH fstools] blockd: don't unmount device when removing it from the list
On 05/12/2018 13:39, Rafał Miłecki wrote: On 2018-12-05 13:31, Paul Oranje wrote: Op 4 dec. 2018, om 12:32 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Device gets removed from the list (vlist_delete()) when block calls "hotplug" method of blockd using ubus. Right after that block unmounts that device on its own. blockd shouldn't care about unmounting on its own for following reasons: 1) To avoid code/behavior duplication with blockThe chicken or the eggThe chicken or the egg 2) To keep behavior consistent with mounting (blockd doesn't mount) 3) To allow implementing more features in block (e.g. hotplug.d events) The design should be to: 1) Have block handle (un)mounting 2) Use blockd for providing devices/mounts state (using ubus) 3) Have blockd handle autofs and call block when needed Can this cause a transition into a state where a device is (still) mounted but removed from the list, and if so, is that a valid, an admissible state ? Shouldn't block be required to first unmount before calling blockd's hotplug entry ? The chicken or the egg? ;) We don't have any mutex/semaphore mechanism in place right now. So unless that gets implemented, we have to chooce what's better. I believe the correct order would be to: 1) Stop reporting mounted device 2) Notify all users about unmounting (hotplug.d event I work on) 3) Unmount That's the safest way that will stop applications from trying to access device due to blockd incorrectly reporting it as mounted. please update the description before pushing Acked-by: John Crispin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Piotr Dymacz 于2018年12月6日周四 上午3:54写道： > > Hi Mathias, > > On 05.12.2018 09:56, Mathias Kresin wrote: > > Hey all, > > > > I would like to start to reject patches for adding boards with only 32 > > MByte of RAM and 4 MByte of flash [0]. These boards barely work with > > todays OpenWrt default builds and require quite some modifications to be > > useful at all [1]. > > In general I agree but I still consider OpenWrt more like a platform > than a ready Linux distribution. For me this means that even if snapshot > or release images are missing for some devices because of their limited > resources, thanks to keeping basic support for them in code base, users > are still able to make use of them. There are already devices in repo > which didn't get official image for 18.06 release but now have snapshot > images and can be even more useful with a custom/self made image. > > > IMHO it doesn't make much sense to waste resources (reviewer time, build > > resources) for boards which will most likely never see an official build > > and/or are more or less unusable with the official build. > > In case of DTS based targets (where single device support in code > doesn't have that big impact like in, for example, ar71xx) and good > quality patch/PR I don't see a reason to not merge the support. And in > case the official snapshot/release build can't fit in available flash > space and we are really worried about build resources, we can just > disable image generation for the device. This way, users and downstream > projects would be still able to make use of OpenWrt on resource-limited > devices without the need to maintain custom device support patches. > > > I prefer to have a joint statement which I can link to, to prevent > > endless discussions or accusations of acting purely arbitrary. > > Instead of making this a strict rule now I would prefer to leave final > decision to the developer who takes care of patch/PR _and_ establish a > clear dead line for this to become a strict rule. Lets say: after 19.06 > release we no longer accept support patches for devices with only 4 MB > of flash or 32 MB of RAM. I'm a user from the Third World. Since devices with 64MB of RAM or more are a little expensive for us. I bought many devices with 1MB flash and 8MB ram, mainly ar9331 qca9533. Then update the RAM to 64MB, and solder a simple sop8 socket to it, and use 4MB 8MB 16MB of flash for it. All works well. > > > I'm not sure whether the topic qualifies for a formal voting, hence the RFC. > > Thanks for bringing up this topic. > > -- > Cheers, > Piotr > > ___ > 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
