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
<> wrote:
> 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
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

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).


--- End Message ---
openwrt-devel mailing list

Reply via email to