[OpenWrt-Devel] [PATCH] ath79: speed up ath9k-eeprom extraction

[Christian Lamparter]

On Friday, February 22, 2019 3:32:03 PM CET Dmitry Tunin wrote:
> пт, 22 февр. 2019 г. в 16:57, Petr Štetiar <ynezz at true.cz>:
> >
> > Dmitry Tunin <hanipouspilot at gmail.com> [2019-02-22 16:13:52]:
> >
> > > What do you mean by "generalize"? Fix it on all platforms, or having
> > > common 10-ath9k-eeprom, 11-ath10k-caldata, etc files., or common code
> > > that will be used on all platforms in some other file?
> > > The first approach is obviously simple enough, but the second is not
> > > that easy, but doable.
> >
> > Simply moving common bits to some generic file which could be shared by all
> > platforms. Something like this for ar71xx, ath79 and ramips, untested.
> > [...]
> >
> > -- ynezz
> 

If I may add something to the discussion, that's probably not on everyone's
radar (apart from mtd-cal-data binding we all know). The plan for the future
is to make use of the upcoming mtd->nvmem provider brigde for both the
caldata and the mac-address update (interestingly enough, this started with
the ipq806x mac-patching thread:
<https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg44616.html>
Only after playing with 950-call-of_get_mac_address-from-device.patch 
I stumbled onto the nvmem development).

Support for reading MTD via the nvmem API was added upstream by commit:
|commit c4dfa25ab307a277eafa7067cd927fbe4d9be4ba
|Author: Alban Bedel <albeu at free.fr>
|Date:   Tue Nov 13 15:01:10 2018 +0100
|
|    mtd: add support for reading MTD devices via the nvmem API
|    
|    Allow drivers that use the nvmem API to read data stored on MTD devices.
|    For this the mtd devices are registered as read-only NVMEM providers.
|    
|    We don't support device tree systems for now.

and

|commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f
|Author: Bartosz Golaszewski <bgolaszewski at baylibre.com>
|Date:   Fri Nov 30 11:53:25 2018 +0000
|
|   nvmem: add new config option
|    
|   We want to add nvmem support for MTD. TI DaVinci is the first platform
|   that will be using it, but only in non-DT mode. In order not to
|   introduce any new interface to supporting of which we would have to
|   commit - add a new config option that tells nvmem not to use the DT
|   node of the parent device.
|    
|   This way we won't be creating nvmem devices corresponding with MTD
|   partitions defined in device tree. By default MTD will set this new
|   field to true.
|   
|   Once a set of bindings for MTD nvmem cells is agreed upon, we'll be
|   able to remove this option.

So the idea right now is that once upstream agreed upon whatever they want
to do with the binding, is to introduce that method and earmark it for new
devices (and people that want to convert their own device). The extraction
scripts will be left in place as a fallback mainly for devices that can't
use the nvmem provider (caldata in a ubi volume, reversed data, etc...).

> The only problem here is that not all platforms need it.
The problem I always have is more along the way that a patch should receive
some "on-device" testing. So I do look forward for patches that received a
"Tested-by:" tag or has positive replies from random/unlikely people. But
we sadly all know that this system has its limits.

Regards,
Christian



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel