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 ---Hi Michal, On Wed, Aug 14, 2019 at 10:59 AM Michal Cieslakiewicz <michal.cieslakiew...@wp.pl> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello Adrian, > > Thanks for helping me with WNR patchset, one question came to my mind > in the process of developing it and after reading one of your emails. > Sorry if it has been answered elsewhere... > > /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts > 4k of calibration data from ART to bin file in /lib/firmware. I > compared bin file to mtd area and they are identical. Why ath9k cannot > use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts > option for? If so, why does it not work in this case? (tested, ath9k > initialization ends with error) > I recall there was no such operation in ar71xx target and older > kernels... (I am the one who brought the /lib/firmware based caldata upstream - these are my thoughts on this topic) upstream ath9k has support for retrieving the caldata through the request_firmware mechanism (which requires copying it to /lib/firmware). some out-of-tree patches have/had a special mtd-cal-data property to achieve a similar goal (passing the caldata to devices without a physical EEPROM). while I upstreamed the ath9k patches for request_firmware support there was a bit of a discussion. the discussion was whether the NVMEM subsystem should be used instead of relying on request_firmware. my primary target was the BT HomeHub 5A which stores the calibration data inside a UBI volume which cannot be referenced from devicetree (yet - or at least at the time I upstreamed the patches it could not be referenced) so I still chose to push the request_firmware part forward. most devices have the caldata at a fixed location on the flash, so the NVMEM subsystem can be used for this. if someone wants to get rid of the caldata copy in /lib/firmware then support for reading the caldata using the NVMEM framework could be implemented in ath9k (and owl-loader). the result would be close to what the mtd-cal-data provides, assuming that the NVMEM subsystem can read the underlying data structures on flash (AFAIK this currently excludes NAND with UBI, which is used by the minority of the boards with an ath9k chip). Martin
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
