Re: [OpenWrt-Devel] [PATCH] mdadm: add new init features; documentation; bug fixes

2019-01-10 Thread Jo-Philipp Wich 
Hi,

comments inline.

> [...]
> + # partition - stateless, mdadm --assemble --scan 
> --config=partition; see mdadm(8)
> + # uci   - stateful, dynamically generated mdadm.conf via uci 
> array values (below),
> + # stored in /var/etc/mdadm.conf
> + #- stateful, manually generated mdadm.conf file(s),
> + #  must be preceded by a / and may be a readable 
> filename

These file tags look wrong.

> [...]
> +#
> +# The mdadm 'array' section(s) are for stateful, manual configurations. 
> Experts only.  Use with caution.
> +#
> +#
> +# The use of multiple 'array' sections is supported by /etc/init.d/mdadm.
> +# They must all be named 'array'.
> +#
> +# As of this writing unnamed 'mdadm' sections are still allowed, but 
> deprecated. Do not use.
> +#

Config "array" sections were used before as well? I do not understand
the deprecation remark.

> +
> +#config array
> + #
> + # example 'array' options may be a valid mix of:
> + #
> + # bitmap
> + # container
> + # device
> + # devices
> + # member
> + # name
> + # spare_group
> + # spares
> + # super_minor
> + # uuid
> + #
>   # option bitmap /bitmap.md
>   # option container :::
> + # option device /dev/md0
> + # -and/or a devices list-
> + # list devices /dev/hd* # mdadm allows glob, see glob(7)
> + # list devices /dev/sd*
> + # list devices /dev/sda1
> + # list devices /dev/sdb1
> + # list devices containers
> + # list devices partitions
>   # option member 1
> + # option name raid:0
> + # option spare_group spares
> + # option spares 0
> + # option super_minor 0
> + # use uuid from block info (preferred), or mdadm --misc --detail 
> /dev/md0
> + # option uuid 2084de11-70c4-4521-8f95-6113e75f1fe9
> + #
> + # These options directly translate to mdadm -- options, see man mdadm(8)

Consider linking to https://linux.die.net/man/8/mdadm, "man" is rarely
available on OpenWrt.

> diff --git a/package/utils/mdadm/files/mdadm.init 
> b/package/utils/mdadm/files/mdadm.init
> index 64a50b3..5453f7d 100644
> --- a/package/utils/mdadm/files/mdadm.init
> +++ b/package/utils/mdadm/files/mdadm.init
> @@ -1,13 +1,21 @@
>  #!/bin/sh /etc/rc.common
>  
> -START=13
> -STOP=98
> +# 20190106, joseph.tingi...@gmail.com, significant revision; new features,
> +#  safer error handling, code formatting,
> +#  & multiple bug fixes

Please drop this comment, changes are recorded in Git & commit message.

> +
> +START=12
> +STOP=X99 # X99? seems to work; passed service enable/disable tests & boot 
> tests

Please stick to plain 99, will change the umount prio in a separate commit.

>  
>  USE_PROCD=1
>  PROG=/sbin/mdadm
>  NAME=mdadm
>  
> -CONF="/var/etc/mdadm.conf"
> +VERBOSE=0 # off
> +
> +TMP_FILE="/var/etc/mdadm.conf" # /var/etc is on /tmp; used for temporary 
> state, to enable stateful only mdadm features

Please remove this comment.

> +
> +[ ! -x "$PROG" ] && exit 1
>  
>  append_list_item() {
>   append "$2" "$1" "$3"
> @@ -30,30 +38,165 @@ append_option() {
>   [ -n "$str" ] && append "$var" $(printf "%s=%s" "${name:-${opt//_/-}}" 
> "$str")
>  }
>  
> -mdadm_common() {
> - local cfg="$1"
> - local email devices
> +verbose() {
> + local msg="$1"
> + local level="$2"
>  
> - if [ -x /usr/sbin/sendmail ]; then
> - config_get email "$cfg" email
> - [ -n "$email" ] && printf "MAILADDR %s\n" "$email" >> $CONF
> + [ -z "$level" ] && level="INFO"
> +
> + if [ "$VERBOSE" == "1" ]; then
> + if [ ${#SSH_TTY} -gt 0 ]; then
> + printf "$NAME: init %7s - %b\n" "$level" "$msg"
> + else
> + # no SSH_TTY goes to logger
> + printf "$NAME: init %7s - %b\n" "$level" "$msg" | 
> logger -t mdadm
> + fi
>   fi

User sessions may not always happen via SSH, could be telnet, uart,
screen. Stick to either variant, independently of $SSH_TTY.

> +}
>  
> - config_list_foreach "$cfg" devices append_list_item devices " "
> - [ -n "$devices" ] && printf "DEVICE %s\n" "$devices" >> $CONF
> +mdadm_conf_auto() {
> + local mdadm_conf="$1"
> +
> + if [ ! -w "$mdadm_conf" ]; then
> + if [ -z "$mdadm_conf" ]; then
> + verbose "mdadm_conf value is empty" ERROR
> + else
> + verbose "'$mdadm_conf' file not found writable" ERROR
> + fi
> + return 1
> + fi
> +
> + local block_md block_uuid mdadm_md mdadm_md_rc mdadm_uuid
> +
> + # Check block info for active linux_raid_members, if necessary then 
> compare with mdadm, & dynamically update $mdadm_conf
> +
> + block_md=0 # counter
> + for block_uuid in $(block info 2> /dev/null | grep

Re: [OpenWrt-Devel] [PATCH v2] mpc85xx: add support for Sophos RED 15w Rev.1

2019-01-10 Thread David Bauer 



On 10.01.19 19:03, Christian Lamparter wrote:
> On Tuesday, January 8, 2019 1:20:56 AM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:  Freescale P1010 PowerPC
>> RAM:  128M DDR3
>> NAND: 128MiB
>> ETH:  RTL8211F SGMII PHY
>>   RTL8367B 5-port RGMII switch
>>   (not connected to SoC - unmanaged)
>> WiFi: SparkLan WPEA-121N
>>- Atheros AR9382 2T2R abgn
>> USB:  1x USB 2.0
>> LED:  System, Router, Internet, Tunnel controllable
>>   LAN1-4, WAN, Power non-controllable
>> BTN:  None
>>
>> Installation
>> 
>> 1. Power on the device while attached to the Console port.
>>
>> 2. Halt the U-Boot by pressing Enter when prompted.
>>
>> 3. Set the correct bootcmd for booting OpenWRT:
>>  > setenv bootargs_owrt "setenv bootargs console=ttyS0,115200"
>>  > setenv bootcmd "run bootargs_owrt;
>>nand read 0x100 0x30 0x80;
>>bootm 0x100;"
>>  > saveenv
>>
>> 5. Rename OpenWRT initramfs image to 'kernel.bin' and place it in a
>>TFTP server root-directory served on 192.168.1.2/24. Connect your
>>computer to one of the LAN-ports.
>>
>> 4. Boot OpenWRT initramfs image with
>>  > run bootargs_owrt; tftpboot 0x100 192.168.1.2:kernel.bin;
>>bootm 0x100;
>>
>> 6. (Optional)
>>Make a Backup of 'sophos-os1', 'sophos-os2' and 'sophos-data' in case
>>you ever want to go back to the vendor firmware.
>>
>> 7. Create Ubi Volume on mtd4 by executing
>>  > ubiformat /dev/mtd4 -y
>>
>> 8. Transfer OpenWRT sysupgrade image to the device via SCP and install it
>>with
>>  > sysupgrade -n 
>>
>> Back to Stock
>> =
>> If you want to go back to the stock firmware, here is the bootcmd of the
>> vendor firmware:
>>  > setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5;
>>nand read 0xc0 0x0030  0x10;
>>nand read 0x100 0x0040 0x0080;
>>bootm 0x100 - 0xc0
>>
>> Set it via 'setenv' from the U-Boot shell and don't forget to save it
>> using 'saveenv'!
>>
>> After this, boot the OpenWRT initramfs image just like you would for
>> installation. Write back the three vendor partitions using mtd. Reboot
>> the device afterwards.
>>
>> Signed-off-by: David Bauer 
>> ---
>> v2:
>>  - move kernel configuration to subtarget
>>  - move nand feature to subtarget
>>  - move partition layout to "fixed-partition" subnode
>>  - add SPDX license-identifier to red15w_rev1.c
>>  - use pr_info instead of printk in red15w_rev1.c
>>
>>  target/linux/mpc85xx/Makefile |   2 +-
>>  target/linux/mpc85xx/base-files/etc/diag.sh   |   3 +
>>  .../etc/hotplug.d/ieee80211/10-fix-wifi-mac   |  20 ++
>>  .../base-files/lib/upgrade/platform.sh|  13 +-
>>  target/linux/mpc85xx/config-4.14  |   1 +
>>  target/linux/mpc85xx/config-4.19  |   1 +
>>  .../arch/powerpc/boot/dts/red-15w-rev1.dts| 207 ++
>>  .../arch/powerpc/platforms/85xx/red15w_rev1.c |  87 
>>  target/linux/mpc85xx/generic/config-default   |  16 ++
>>  target/linux/mpc85xx/generic/target.mk|   1 +
>>  target/linux/mpc85xx/image/Makefile   |  12 +
>>  target/linux/mpc85xx/p1020/target.mk  |   1 -
>>  .../104-powerpc-85xx-red-15w-rev1.patch   |  33 +++
>>  .../103-powerpc-85xx-red-15w-rev1.patch   |  33 +++
>>  14 files changed, 427 insertions(+), 3 deletions(-)
>>  create mode 100644 
>> target/linux/mpc85xx/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac
>>  create mode 100644 
>> target/linux/mpc85xx/files/arch/powerpc/boot/dts/red-15w-rev1.dts
>>  create mode 100644 
>> target/linux/mpc85xx/files/arch/powerpc/platforms/85xx/red15w_rev1.c
>>  create mode 100644 
>> target/linux/mpc85xx/patches-4.14/104-powerpc-85xx-red-15w-rev1.patch
>>  create mode 100644 
>> target/linux/mpc85xx/patches-4.19/103-powerpc-85xx-red-15w-rev1.patch
>>
>> diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
>> index 552f16e82f..0affc38f61 100644
>> --- a/target/linux/mpc85xx/Makefile
>> +++ b/target/linux/mpc85xx/Makefile
>> @@ -10,7 +10,7 @@ ARCH:=powerpc
>>  BOARD:=mpc85xx
>>  BOARDNAME:=Freescale MPC85xx
>>  CPU_TYPE:=8540
>> -FEATURES:=squashfs
>> +FEATURES:=squashfs ramdisk
>>  MAINTAINER:=Imre Kaloz 
>>  SUBTARGETS:=generic p1020
>>  
> 
> Hm, this might clash with the github PR:
> "mpc85xx: add support for Freescale (NXP) P2020RDB"
>  since
> he seemingly disabled (commented it out, but left it in place)
> the ramdisk feature for his p2020.

I assume it's kind of an oversight.

I don't see a reason why the generation of a ramdisk image would be
problem for the target as a whole (worst case: it doesn't boot).

But I'm fine with enabling ramdisk support only for the generic subtarget.

Best wishes
David

> I've notified Pawel as well. I don't really think this is much of an
> issue and both of you are currently familiar with the target
> and the devices. I'm fine with just a short note whenever the feature
>

Re: [OpenWrt-Devel] flock clash with msmtpq-ng-mta

2019-01-10 Thread Marcel Telka 
On Thu, Jan 10, 2019 at 12:23:09AM -0500, Daniel F. Dickinson wrote:
> On 2019-01-07 4:57 p.m., Marcel Telka wrote:
> > On Sat, Jan 05, 2019 at 03:54:52AM -0500, Daniel F. Dickinson wrote:
> >> On 2019-01-04 2:14 a.m., Marcel Telka wrote:
> >>> Hi,
> >>>
> >>> After upgrade from LEDE 17.01.4 to OpenWrt 18.06.1 I noticed that
> >>> mailq from
> >>> the msmtpq-ng-mta package no longer works:
> >>>
> >> So I have bad news -- I'm upstream and I deprecated / abandoned the
> >> msmtpq-ng as a bad idea.  I could probably be convinced to bring it back
> >> if there were use cases that actually made sense (what I realized is
> >> that the queuing was of limited use on flash system because a reboot
> >> loses all queued messages anyway in the default (RAM) config, and I
> >> wouldn't want to queue onto flash for limited writes concerns).  If
> >> there was a good case I think I'd fixup the shell script only until I
> >> had replaced it with a decent C implementation of a similar concept
> >> (preferably using a reasonably small smtp library to do avoid
> >> reinventing the wheel).
> > 
> > Okay, thanks for the info.
> > 
> > My use case is simple: I have a site (small household) with only one device
> > running all the time (a cheap openwrt router).  I would like to run some
> > non-critical cron jobs on the router and I'd like to get email notifications
> > from them once completed.  I found that simple mail queue support as 
> > provided
> > by msmtpq-ng-mta is good enough to cover rare internet connection issues.  
> > I do
> > not need to have a bullet proof system with zero lost mails, so in-RAM 
> > queue is
> > good enough.  When I did my research few years back to find the best 
> > solution I
> > just found msmtpq-ng-mta and started to use it.  It perfectly fits my 
> > needs.  A
> > possible solution with added some small additional device (like a Raspberry 
> > Pi)
> > is just an overkill for this use case and cannot be reasonably justified.
> > 
> > Is there any other simple solution that could be used for sending mails,
> > preferably with simple queuing support, and with ability to submit mails 
> > using
> > TLS and SMTP AUTH?
> > 
> 
> There isn't that I am aware of.  I actually think I will pull the
> project out of mothball mode and do some updates.  I'll try and look at

That would be great.

> the 18.06 branch and what can be done 'soon'.  I may not make the merge
> window for the next batch of releases as I believe fork is on about the
> 12th.

There is not a need for anything to be done 'soon'.  My current setup with the
workaround works well.

> In the meantime have you tried installing 'full' flock and logger
> utilities?  That may solve your issue for now.

No.  I have no free space for that.  But that's not a problem because simple
flock symlink removal solves the problem for me (as I mentioned in the first
post).  So I do not need any other interim solution.


Thank you.

-- 
+---+
| Marcel Telka   e-mail:   mar...@telka.sk  |
|homepage: http://telka.sk/ |
|jabber:   mar...@jabber.sk |
+---+

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

Re: [OpenWrt-Devel] [PATCH v2] mpc85xx: add support for Sophos RED 15w Rev.1

2019-01-10 Thread Christian Lamparter 
On Tuesday, January 8, 2019 1:20:56 AM CET David Bauer wrote:
> Hardware
> 
> CPU:  Freescale P1010 PowerPC
> RAM:  128M DDR3
> NAND: 128MiB
> ETH:  RTL8211F SGMII PHY
>   RTL8367B 5-port RGMII switch
>   (not connected to SoC - unmanaged)
> WiFi: SparkLan WPEA-121N
>- Atheros AR9382 2T2R abgn
> USB:  1x USB 2.0
> LED:  System, Router, Internet, Tunnel controllable
>   LAN1-4, WAN, Power non-controllable
> BTN:  None
> 
> Installation
> 
> 1. Power on the device while attached to the Console port.
> 
> 2. Halt the U-Boot by pressing Enter when prompted.
> 
> 3. Set the correct bootcmd for booting OpenWRT:
>  > setenv bootargs_owrt "setenv bootargs console=ttyS0,115200"
>  > setenv bootcmd "run bootargs_owrt;
>nand read 0x100 0x30 0x80;
>bootm 0x100;"
>  > saveenv
> 
> 5. Rename OpenWRT initramfs image to 'kernel.bin' and place it in a
>TFTP server root-directory served on 192.168.1.2/24. Connect your
>computer to one of the LAN-ports.
> 
> 4. Boot OpenWRT initramfs image with
>  > run bootargs_owrt; tftpboot 0x100 192.168.1.2:kernel.bin;
>bootm 0x100;
> 
> 6. (Optional)
>Make a Backup of 'sophos-os1', 'sophos-os2' and 'sophos-data' in case
>you ever want to go back to the vendor firmware.
> 
> 7. Create Ubi Volume on mtd4 by executing
>  > ubiformat /dev/mtd4 -y
> 
> 8. Transfer OpenWRT sysupgrade image to the device via SCP and install it
>with
>  > sysupgrade -n 
> 
> Back to Stock
> =
> If you want to go back to the stock firmware, here is the bootcmd of the
> vendor firmware:
>  > setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5;
>nand read 0xc0 0x0030  0x10;
>nand read 0x100 0x0040 0x0080;
>bootm 0x100 - 0xc0
> 
> Set it via 'setenv' from the U-Boot shell and don't forget to save it
> using 'saveenv'!
> 
> After this, boot the OpenWRT initramfs image just like you would for
> installation. Write back the three vendor partitions using mtd. Reboot
> the device afterwards.
> 
> Signed-off-by: David Bauer 
> ---
> v2:
>  - move kernel configuration to subtarget
>  - move nand feature to subtarget
>  - move partition layout to "fixed-partition" subnode
>  - add SPDX license-identifier to red15w_rev1.c
>  - use pr_info instead of printk in red15w_rev1.c
> 
>  target/linux/mpc85xx/Makefile |   2 +-
>  target/linux/mpc85xx/base-files/etc/diag.sh   |   3 +
>  .../etc/hotplug.d/ieee80211/10-fix-wifi-mac   |  20 ++
>  .../base-files/lib/upgrade/platform.sh|  13 +-
>  target/linux/mpc85xx/config-4.14  |   1 +
>  target/linux/mpc85xx/config-4.19  |   1 +
>  .../arch/powerpc/boot/dts/red-15w-rev1.dts| 207 ++
>  .../arch/powerpc/platforms/85xx/red15w_rev1.c |  87 
>  target/linux/mpc85xx/generic/config-default   |  16 ++
>  target/linux/mpc85xx/generic/target.mk|   1 +
>  target/linux/mpc85xx/image/Makefile   |  12 +
>  target/linux/mpc85xx/p1020/target.mk  |   1 -
>  .../104-powerpc-85xx-red-15w-rev1.patch   |  33 +++
>  .../103-powerpc-85xx-red-15w-rev1.patch   |  33 +++
>  14 files changed, 427 insertions(+), 3 deletions(-)
>  create mode 100644 
> target/linux/mpc85xx/base-files/etc/hotplug.d/ieee80211/10-fix-wifi-mac
>  create mode 100644 
> target/linux/mpc85xx/files/arch/powerpc/boot/dts/red-15w-rev1.dts
>  create mode 100644 
> target/linux/mpc85xx/files/arch/powerpc/platforms/85xx/red15w_rev1.c
>  create mode 100644 
> target/linux/mpc85xx/patches-4.14/104-powerpc-85xx-red-15w-rev1.patch
>  create mode 100644 
> target/linux/mpc85xx/patches-4.19/103-powerpc-85xx-red-15w-rev1.patch
> 
> diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
> index 552f16e82f..0affc38f61 100644
> --- a/target/linux/mpc85xx/Makefile
> +++ b/target/linux/mpc85xx/Makefile
> @@ -10,7 +10,7 @@ ARCH:=powerpc
>  BOARD:=mpc85xx
>  BOARDNAME:=Freescale MPC85xx
>  CPU_TYPE:=8540
> -FEATURES:=squashfs
> +FEATURES:=squashfs ramdisk
>  MAINTAINER:=Imre Kaloz 
>  SUBTARGETS:=generic p1020
>  

Hm, this might clash with the github PR:
"mpc85xx: add support for Freescale (NXP) P2020RDB"
 since
he seemingly disabled (commented it out, but left it in place)
the ramdisk feature for his p2020.

I've notified Pawel as well. I don't really think this is much of an
issue and both of you are currently familiar with the target
and the devices. I'm fine with just a short note whenever the feature
should be enabled for all targets or just those the individual 
subtargets and I'll then make the change locally.

Thanks,
Christian



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

[OpenWrt-Devel] [PATCH] generic: ar8216: ar8327: kill warnings

2019-01-10 Thread Chuanhong Guo 
This fixed warnings caused by returning value in a void function

Signed-off-by: Chuanhong Guo 
---
 target/linux/generic/files/drivers/net/phy/ar8327.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c 
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 13e911bbc3..5af6aaf6f2 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -139,7 +139,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct 
phy_device *phydev)
 
if (!of_property_read_bool(np, "qca,phy-rgmii-en")) {
pr_err("ar8327: qca,phy-rgmii-en is not specified\n");
-   return -EINVAL;
+   return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_MODE_SEL, _val);
@@ -150,7 +150,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct 
phy_device *phydev)
/* 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;
+   return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_SYS_CTRL, _val);
@@ -161,7 +161,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct 
phy_device *phydev)
/* 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;
+   return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_TEST_CTRL, _val);
-- 
2.20.1


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

[OpenWrt-Devel] umbim: registration set support

2019-01-10 Thread Ingo Feinerer 
Hi,

this mail gives a detailed background explanation and motivation for the patch
"[PATCH] umbim: add registration set support" (the analysis is probably too
lengthy to be included as a commit message).

I am using a Medion S4222 (MediaTek OEM) USB stick and it failed to
connect in OpenWrt:

# umbim -n -d /dev/cdc-wdm0 connect "drei.at"
sending (124): 03 00 00 00 7c 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 a2 
89 cc 33 bc bb 8b 4f b6 b0 13 3e c2
aa e6 df 0c 00 00 00 01 00 00 00 4c 00 00 00 00 00 00 00 01 00 00 00 3c 00 00 
00 0e 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 5e 2a 7e 4e 
6f 72 72 73 6b 65 6e 7e 5e 2a 7e 64
00 72 00 65 00 69 00 2e 00 61 00 74 00 00 00
  header_type: 0003
  header_length: 007C
  header_transaction: 0007
reading (48): 03 00 00 80 30 00 00 00 07 00 00 00 01 00 00 00 00 00 00 00 a2 89 
cc 33 bc bb 8b 4f b6 b0 13 3e c2 aa
e6 df 0c 00 00 00 07 00 00 00 00 00 00 00
  header_type: 8003
  header_length: 0030
  header_transaction: 0007
  command_id: 000C
  status_code: 0007

According to the MBIM specification the status code means:

MBIM_STATUS_NOT_REGISTERED 7
The operation failed because the device is not registered with any network.

Unfortunately, just calling the registration function in query mode
before the connect attempt is not enough in my setup:

# umbim -n -d /dev/cdc-wdm0 registration
  nwerror:  - unknown
  registerstate: 0004 - roaming
  registermode: 0001 - automatic
  availabledataclasses: 0018 - (null)
  currentcellularclass: 0001 - gsm
  provider_id: 23205
  provider_name: 23205
  roamingtext: (null)

With the new function the connect method succeeds and gives me a working
IPv4 address.

# umbim -n -d /dev/cdc-wdm0 registration automatic
  nwerror:  - unknown
  registerstate: 0003 - home
  registermode: 0001 - automatic
  availabledataclasses: 0018 - (null)
  currentcellularclass: 0001 - gsm
  provider_id: 23210
  provider_name: 23210
  roamingtext: (null)

As you see the registerstate is now "home" and there was a mobile
network code change (23205 -> 23210).

The MBIM specification mentions that both manual and automatic
registration could be possible. I only implemented automatic; this seems
to be in line with what mbimcli supports (--register-automatic); see
https://manpages.debian.org/stretch/libmbim-utils/mbimcli.1.en.html. I
assume that any argument (_argc > 0) triggers the setter so that the
call could look like

umbim ... registration automatic
or
umbim ... registration on

and allows one to extended it later for manual setting with additional
arguments for the manual registration process.

As the existing call convention (i.e., no arguments) is not modified
existing scripts (like /lib/netifd/proto/mbim.sh in OpenWrt) still
work without adaption.

Note that

rs->registeraction = htole32(MBIM_REGISTER_ACTION_AUTOMATIC)

is redundant as MBIM_REGISTER_ACTION_AUTOMATIC is defined as 0 (and the
whole buffer is memset to zero before) but I thought it is clearer for the
reader.

Thanks a lot for consideration!

Best regards,
Ingo


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

[OpenWrt-Devel] [PATCH] umbim: add registration set support

2019-01-10 Thread Ingo Feinerer 
This implements the MBIM automatic registration mode to let the function
select the best provider network.

Signed-off-by: Ingo Feinerer 
---
 cli.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/cli.c b/cli.c
index 1dd6330..e00b6d4 100644
--- a/cli.c
+++ b/cli.c
@@ -297,7 +297,16 @@ mbim_pin_state_request(void)
 static int
 mbim_registration_request(void)
 {
-   mbim_setup_command_msg(basic_connect, MBIM_MESSAGE_COMMAND_TYPE_QUERY, 
MBIM_CMD_BASIC_CONNECT_REGISTER_STATE, 0);
+   if (_argc > 0) {
+   struct mbim_basic_connect_register_state_s *rs =
+   (struct mbim_basic_connect_register_state_s *) 
mbim_setup_command_msg(basic_connect,
+   MBIM_MESSAGE_COMMAND_TYPE_SET, 
MBIM_CMD_BASIC_CONNECT_REGISTER_STATE,
+   sizeof(struct 
mbim_basic_connect_register_state_s));
+
+   rs->registeraction = htole32(MBIM_REGISTER_ACTION_AUTOMATIC);
+   } else {
+   mbim_setup_command_msg(basic_connect, 
MBIM_MESSAGE_COMMAND_TYPE_QUERY, MBIM_CMD_BASIC_CONNECT_REGISTER_STATE, 0);
+   }
 
return mbim_send_command_msg();
 }
-- 
2.20.1


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

Re: [OpenWrt-Devel] Pending ath79 issues on ar9342 and 4.14/4.19 kernels

2019-01-10 Thread Petr Štetiar 
Petr Štetiar  [2019-01-02 01:24:22]:

> 1. MAC reset issue
> 
>  While converting UBNT Nanostation M XW to ath79, I've found out, that the MAC
>  isn't properly reset on ath79, resulting in disfunctional networking due to
>  MAC_CFG2_CRC_EN bit set in AG71XX_REG_MAC_CFG2. My first naive attempt to fix
>  this issue[A], but I wasn't satisfied with this fix it so I've asked for help
>  with proper fix.
> 
>  With the help of blogic/Guo I've found out, that we need to reset MDIO/GMAC 
> in
>  one step, otherwise resetting of MAC doesn't work. ar71xx does this, but 
> ath79
>  doesn't, in ath79 we reset MDIO and GMAC separately. I'm able to reset MAC
>  properly in ath79 with following changes:
> 
>{
> reset-names = "mac", "mdio";
> resets = < 9>, < 22>;
>   };
> 
>  and using `devm_reset_control_array_get_exclusive` to reset the MAC. But then
>  there's issue with MDIO configuration, since MDIO is configured/probed before
>  MAC reset and issue with fast reset as well, since on ar71xx it's only
>  reseting GMAC0 (bit 9) so it needs someone with better complete picture to 
> fix
>  it properly.

Seems to be fixed in https://github.com/openwrt/openwrt/pull/1735

> 2. Different MDIO divider values
> 
>  I've observed this on UBNT Bullet M XW.  On ar71xx it's using
>  MII_CFG_CLK_DIV_58 fallback value because ag71xx_mdio_get_divider() doesn't
>  return anything, but on ath79 it's using MII_CFG_CLK_DIV_50 as computed in
>  ag71xx_mdio_get_divider(). I'm not sure if it has significant impact on
>  anything.

Still unsure about this one.

> 3. TX hang workaround is not enabled (DMA engine stuck)
> 
>  On ath79 we enable this workaround only for `qca,ar7240-eth`, but in ar71xx
>  it's enabled for is_ar724x SoCs (ar724x, ar933x, ar934x, qca9533, tp9343,
>  qca955x, qca956x). What is correct? To me it seems, that we should enable it
>  for same set of SoCs in ath79 as well, but I'm not 100% sure.

Still unsure about this one, but proposed fix in 
https://patchwork.ozlabs.org/patch/1020748/

> 4. Transmit queue 0 timed out
> 
>  On ath79 and UBNT Bullet M XW I'm experiencing weird issues during network
>  setup[B] which I'm able to reproduce easily with following commands:
> 
>   uci set network.lan.ipaddr='192.168.1.20'
>   uci commit network
>   ifup lan
> 
>  Resulting after some time in:
> 
>   ...
>   WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 
> dev_watchdog+0x16c/0x280
>   NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
>   ...
> 
>  Sometimes I'm not able to use networking anymore, sometimes it's enough to
>  just ifdown/ifup lan and the network is backup.
> 
>  While trying to fix this issue, I've found out about 2. and 3., but fixing
>  them in the same way as on ar71xx doesn't help with this issue. Proper MAC
>  reset as described in 1. doesn't help with this issue either.
> 
>  Any idea what might possibly cause this? Dump of registers looks same on
>  ar71xx/ath79 so it's probably something related to code path changes.

Seems to be fixed in https://patchwork.ozlabs.org/patch/1020158/

-- ynezz

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