When trying to get the FXS ports on my ZyXEL P2812-HNU-F1 working, I found this documentation. To enable the FXS ports I had to add the lines
status = "okay";
to the dts file, and change the kernel cmdline in the dts file to console=ttyLTQ0,115200 mem=126M vpe1_load_addr=0x87e00000 vpe1_mem=2M maxvpes=1 maxtcs=1 nosmp
and build an image. To my surprise the kernel modules from the 18.06.rc2 repository were not compatible to my own-build 18.06.rc2 kernel (I got a "tapi_open: error finding DrvCtx") so I had to include ltq_drv_tapi and ltq_drv_vmmc also.
Now I wonder if that can't be easier. Does it hurt to have vmmc 'okayed' by default on lantiq devices with FXS ports? The commandline does hurt. It costs a CPU and 2MB ram. But to install OpenWrt on a P2812-HNU-FX (and AFAIK on any lantiq device) you have to exchange u-boot. So using the serial port, or even uboot-tools I can easily change the command line provided by u-boot.
My proposal is to 'okay' vmmc in the dts file by default, and let the u-boot provided cmdline override the dts provided one, when some keyword is provided. This way the stock image is capable to support the FXS ports.
But given that you're half way there, the best course of action would be to submit a patch to the mailing list or file a pull request on github instead - make sure that you will also have to add the required DEVICE_PACKAGES (probably kmod-ltq-tapi kmod-ltq-vmmc) to your device's image generation code as well:
If you go this route of submitting patch for the ZyXEL P2812-HNU-F1 yourself, please refer to https://openwrt.org/submitting-patches for general information and spend a little effort on following the advice given there (signing off your commit and following general coding style/ not introducing spurious whitespace matters).
In general, yes, if a device has functional FXS ports that can be used under OpenWrt, they should usually be enabled in the DTS by default. The reason why they haven't been so far is probably because the initial patch submitter didn't look into the topic for their own needs, respectively because they may have cared more about the performance advantage of using the second core for general processing needs (to improve the WAN-to-LAN routing performance), rather than demoting it as a voice core exclusively.
But yes, the general consensus as exhibited in similar devices, is to enable the VMMC in the DTS - and to override the cmdline via DTS to enable it (and to disable SMP at the same time) for devices that can use it.
Once you do recompile the the kernel, the version string will change and prevent you from installing stock OpenWrt kernel modules, as the kernel ABI will have changed due to the different version/ different kernel configuration - which could result in kernel crashes if you'd mix them with your own compilation; the general advice is - once you do modify the kernel, make sure to enable everything you need (even include it statically into your firmware image), so everything follows the same ABI.
Yep I feel the same,
In my opinion the the best solution will be when the image builder create the kernel from dts + vmlinuz again.
And more better too will be when an extended mode exist where the complete make image process will do again.
Creating the kernel from DTS and vmlinuz is possible by using the imagebuilder + SDK but it is a "hack" and you need the exact commandlines for building the kernel.
(You can get it if you build it from source.)
I have do it in post 76 for LEDE-17 see add-VMMC.tar.gz
(OT: is there no search funktion in the archived forum ?)
I ask my self how solve the developer this problem ?