* [PATCH 1/3] drivers: Add an API to read device specific config data
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
@ 2017-02-27 20:28 ` Alban
2017-02-27 20:28 ` [PATCH 2/3] mtd: Add support for reading device data out of MTD devices Alban
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Alban @ 2017-02-27 20:28 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mtd, Cyrille Pitchen, Richard Weinberger, Marek Vasut,
Boris Brezillon, Brian Norris, David Woodhouse,
Greg Kroah-Hartman, Alban Bedel
From: Alban Bedel <albeu@free.fr>
Some device need configuration data that is specific to this
particular device instance, for example some calibration results,
or a MAC address. Most often this data is stored in some EEPROM
or MTD device.
This API follow the usual provider/consumer pattern to give device
drivers a simple way to read such config data. Storage devices can
register themself as data provider and the platform code, or DT,
define the mapping betwen the devices and their data. Device drivers
can then read the data with a simple read call with a connection ID,
offset and size.
Currently the lookup first attempts to read the data from the
filesystem in /etc/devices/<DEVNAME>/<CONNECTION_ID>. This allow the
users to override the board data if they need to.
If the filesystem lookup fails it then fallback on DT. The consumer
device's OF node should have a property named <CONNECTION_ID>-data
that contains a phandle to the device, or partition, providing the
data. The phandle can have one argument that give the base offset
used to access this particular data.
If the OF lookup fails it then fallback on registrations from platform
code, here both the consumer and provider are just matched on device
name.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/base/Kconfig | 6 ++
drivers/base/Makefile | 1 +
drivers/base/devdata.c | 204 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/devdata.h | 79 +++++++++++++++++++
4 files changed, 290 insertions(+)
create mode 100644 drivers/base/devdata.c
create mode 100644 include/linux/devdata.h
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d718ae4..b7defd0 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -165,6 +165,12 @@ config FW_LOADER_USER_HELPER_FALLBACK
If you are unsure about this, say N here.
+config DEVDATA
+ bool
+ help
+ Drivers should "select" this option if they need to load device
+ specific data.
+
config WANT_DEV_COREDUMP
bool
help
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index f2816f6..cd8fbc5 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SOC_BUS) += soc.o
obj-$(CONFIG_PINCTRL) += pinctrl.o
obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
+obj-$(CONFIG_DEVDATA) += devdata.o
obj-y += test/
diff --git a/drivers/base/devdata.c b/drivers/base/devdata.c
new file mode 100644
index 0000000..7d3b42f
--- /dev/null
+++ b/drivers/base/devdata.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2015 Alban Bedel <albeu@free.fr>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/devdata.h>
+#include <linux/device.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/of.h>
+
+static DEFINE_MUTEX(devdata_provider_list_mutex);
+static LIST_HEAD(devdata_provider_list);
+
+static DEFINE_MUTEX(devdata_lookup_list_mutex);
+static LIST_HEAD(devdata_lookup_list);
+
+void devdata_provider_register(struct devdata_provider *provider)
+{
+ mutex_lock(&devdata_provider_list_mutex);
+ list_add_tail(&provider->list, &devdata_provider_list);
+ mutex_unlock(&devdata_provider_list_mutex);
+}
+
+void devdata_provider_unregister(struct devdata_provider *provider)
+{
+ mutex_lock(&devdata_provider_list_mutex);
+ list_del(&provider->list);
+ mutex_unlock(&devdata_provider_list_mutex);
+}
+
+static void __devdata_provider_unregister(void *provider)
+{
+ devdata_provider_unregister(provider);
+}
+
+int devm_devdata_provider_register(struct device *dev,
+ struct devdata_provider *provider)
+{
+ int err;
+
+ devdata_provider_register(provider);
+ err = devm_add_action(
+ dev, __devdata_provider_unregister, provider);
+ if (err)
+ devdata_provider_unregister(provider);
+ return err;
+}
+
+void devm_devdata_provider_unregister(struct device *dev,
+ struct devdata_provider *provider)
+{
+ devm_remove_action(dev, __devdata_provider_unregister, provider);
+ devdata_provider_unregister(provider);
+}
+
+static int devdata_fs_read(struct device *dev, const char *id,
+ loff_t offset, void *buffer, size_t size)
+{
+ struct file *fp;
+ char *path;
+ int len;
+
+ path = __getname();
+ if (!path)
+ return -ENOMEM;
+
+ len = snprintf(path, PATH_MAX, "/etc/devices/%s/%s",
+ dev_name(dev), id);
+ if (len >= PATH_MAX) {
+ __putname(path);
+ return -ENAMETOOLONG;
+ }
+
+ fp = filp_open(path, O_RDONLY, 0);
+ __putname(path);
+ if (IS_ERR(fp))
+ return PTR_ERR(fp);
+
+ len = kernel_read(fp, offset, buffer, size);
+ fput(fp);
+
+ return len == size ? 0 : -EIO;
+}
+
+static int devdata_of_read(struct device *dev, const char *id,
+ loff_t offset, void *buffer, size_t size)
+{
+ struct of_phandle_args args;
+ struct devdata_provider *p;
+ int err, base = 0;
+ char prop[64];
+
+ snprintf(prop, sizeof(prop), "%s-data", id);
+ if (!of_find_property(dev->of_node, prop, NULL))
+ return -ENOENT;
+
+ err = of_parse_phandle_with_args(dev->of_node, prop,
+ "#data-provider-cells", 0, &args);
+ if (err)
+ return err;
+
+ switch (args.args_count) {
+ case 0:
+ break;
+ case 1:
+ base = args.args[0];
+ break;
+ default:
+ dev_err(dev, "Unsupported data provider cells count\n");
+ return -EINVAL;
+ }
+
+ err = -EPROBE_DEFER;
+ mutex_lock(&devdata_provider_list_mutex);
+ list_for_each_entry(p, &devdata_provider_list, list) {
+ if (p->dev->of_node != args.np)
+ continue;
+
+ err = p->read(p->dev, buffer, base + offset, size);
+ break;
+ }
+ mutex_unlock(&devdata_provider_list_mutex);
+
+ return err;
+}
+
+static int devdata_platform_read(struct device *dev, const char *id,
+ loff_t offset, void *buffer, size_t size)
+{
+ struct devdata_provider *p;
+ struct devdata_lookup *l;
+ int err = -EPROBE_DEFER;
+ bool found = false;
+
+ mutex_lock(&devdata_lookup_list_mutex);
+ list_for_each_entry(l, &devdata_lookup_list, list) {
+ if (strcmp(dev_name(dev), l->dev_id))
+ continue;
+ if (strcmp(id, l->con_id))
+ continue;
+ found = true;
+ break;
+ }
+
+ if (!found) {
+ mutex_unlock(&devdata_lookup_list_mutex);
+ return -ENOENT;
+ }
+
+ mutex_lock(&devdata_provider_list_mutex);
+ list_for_each_entry(p, &devdata_provider_list, list) {
+ if (strcmp(dev_name(p->dev), l->provider))
+ continue;
+
+ err = p->read(p->dev, buffer, l->offset + offset, size);
+ break;
+ }
+ mutex_unlock(&devdata_provider_list_mutex);
+ mutex_unlock(&devdata_lookup_list_mutex);
+
+ return err;
+}
+
+int devdata_read(struct device *dev, const char *id, loff_t offset,
+ void *buffer, size_t size)
+{
+ int err;
+
+ if (!dev || !id || !buffer)
+ return -EINVAL;
+
+ err = devdata_fs_read(dev, id, offset, buffer, size);
+
+ if (err == -ENOENT)
+ err = devdata_of_read(dev, id, offset, buffer, size);
+
+ if (err == -ENOENT)
+ err = devdata_platform_read(dev, id, offset, buffer, size);
+
+ return err;
+}
+
+void devdata_lookup_register(struct devdata_lookup *lookup, size_t num)
+{
+ mutex_lock(&devdata_lookup_list_mutex);
+ while (num--)
+ list_add_tail(&lookup->list, &devdata_lookup_list);
+ mutex_unlock(&devdata_lookup_list_mutex);
+}
+
+void devdata_lookup_unregister(struct devdata_lookup *lookup, size_t num)
+{
+ mutex_lock(&devdata_lookup_list_mutex);
+ while (num--)
+ list_del(&lookup->list);
+ mutex_unlock(&devdata_lookup_list_mutex);
+}
diff --git a/include/linux/devdata.h b/include/linux/devdata.h
new file mode 100644
index 0000000..70275e6
--- /dev/null
+++ b/include/linux/devdata.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2015 Alban Bedel <albeu@free.fr>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_DEVDATA_H
+#define __LINUX_DEVDATA_H
+
+#include <linux/list.h>
+
+struct device;
+
+struct devdata_lookup {
+ struct list_head list;
+ const char *dev_id;
+ const char *con_id;
+ const char *provider;
+ unsigned int offset;
+};
+
+struct devdata_provider {
+ struct list_head list;
+ struct device *dev;
+
+ int (*read)(struct device *dev, void *buffer,
+ loff_t offset, size_t size);
+};
+
+#ifdef CONFIG_DEVDATA
+
+void devdata_provider_register(struct devdata_provider *provider);
+void devdata_provider_unregister(struct devdata_provider *provider);
+
+int devm_devdata_provider_register(struct device *dev,
+ struct devdata_provider *provider);
+void devm_devdata_provider_unregister(struct device *dev,
+ struct devdata_provider *provider);
+
+int devdata_read(struct device *dev, const char *id,
+ loff_t offset, void *buffer, size_t size);
+
+void devdata_lookup_register(struct devdata_lookup *lookup, size_t num);
+void devdata_lookup_unregister(struct devdata_lookup *lookup, size_t num);
+
+#else
+
+static inline void devdata_provider_register(
+ struct devdata_provider *provider){}
+
+static inline void devdata_provider_unregister(
+ struct devdata_provider *provider){}
+
+static inline int devm_devdata_provider_register(
+ struct device *dev, struct devdata_provider *provider)
+{
+ return 0;
+}
+
+static inline void devm_devdata_provider_unregister(
+ struct device *dev, struct devdata_provider *provider){}
+
+static inline int devdata_read(struct device *dev, const char *id,
+ loff_t offset, void *buffer, size_t size)
+{
+ return -ENOENT;
+}
+
+static inline void devdata_lookup_register(
+ struct devdata_lookup *lookup, size_t num){}
+static inline void devdata_lookup_unregister(
+ struct devdata_lookup *lookup, size_t num){}
+
+#endif /* CONFIG_DEVDATA */
+
+#endif /* __LINUX_DEVDATA_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 2/3] mtd: Add support for reading device data out of MTD devices
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
2017-02-27 20:28 ` [PATCH 1/3] " Alban
@ 2017-02-27 20:28 ` Alban
2017-02-27 20:28 ` [PATCH 3/3] ath9k: ahb: Add OF support Alban
` (2 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Alban @ 2017-02-27 20:28 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mtd, Cyrille Pitchen, Richard Weinberger, Marek Vasut,
Boris Brezillon, Brian Norris, David Woodhouse,
Greg Kroah-Hartman, Alban Bedel
From: Alban Bedel <albeu@free.fr>
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/mtd/Kconfig | 9 +++++++
drivers/mtd/Makefile | 1 +
drivers/mtd/devdata.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+)
create mode 100644 drivers/mtd/devdata.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index e83a279..b08a1c0 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -322,6 +322,15 @@ config MTD_PARTITIONED_MASTER
the parent of the partition device be the master device, rather than
what lies behind the master.
+config MTD_DEVDATA
+ tristate "Read device data from MTD device"
+ default y
+ depends on DEVDATA
+ help
+ This provides support for reading device data from MTD devices.
+ This is can be used by drivers to read device specific data such as
+ MAC address or calibration results.
+
source "drivers/mtd/chips/Kconfig"
source "drivers/mtd/maps/Kconfig"
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1..7d99768 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o
obj-$(CONFIG_MTD_BCM63XX_PARTS) += bcm63xxpart.o
obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
+obj-$(CONFIG_MTD_DEVDATA) += devdata.o
# 'Users' - code which presents functionality to userspace.
obj-$(CONFIG_MTD_BLKDEVS) += mtd_blkdevs.o
diff --git a/drivers/mtd/devdata.c b/drivers/mtd/devdata.c
new file mode 100644
index 0000000..68412b1e
--- /dev/null
+++ b/drivers/mtd/devdata.c
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2015 Alban Bedel <albeu@free.fr>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/devdata.h>
+#include <linux/of.h>
+
+int mtd_devdata_provider_read(struct device *dev, void *buffer,
+ loff_t offset, size_t size)
+{
+ struct mtd_info *mtd = container_of(dev, struct mtd_info, dev);
+ size_t retlen;
+ int err;
+
+ err = mtd_read(mtd, offset, size, &retlen, buffer);
+ if (err && err != -EUCLEAN)
+ return err;
+ return retlen == size ? 0 : -EIO;
+}
+
+static void mtd_devdata_provider_add(struct mtd_info *mtd)
+{
+ struct device *dev = &mtd->dev;
+ struct device_node *np = dev_of_node(dev);
+ struct devdata_provider *p;
+
+ /* OF devices have to provide the data-provider node */
+ if (np && !of_property_read_bool(np, "data-provider"))
+ return;
+
+ p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL);
+ p->dev = dev;
+ p->read = mtd_devdata_provider_read;
+
+ if (devm_devdata_provider_register(dev, p))
+ dev_warn(dev, "Failed to register as devdata provider\n");
+}
+
+static void mtd_devdata_provider_remove(struct mtd_info *mtd)
+{
+}
+
+static struct mtd_notifier mtd_devdata_provider_notifier = {
+ .add = mtd_devdata_provider_add,
+ .remove = mtd_devdata_provider_remove,
+};
+
+static int __init mtd_devdata_init(void)
+{
+ register_mtd_user(&mtd_devdata_provider_notifier);
+ return 0;
+}
+module_init(mtd_devdata_init);
+
+static void __exit mtd_devdata_exit(void)
+{
+ unregister_mtd_user(&mtd_devdata_provider_notifier);
+}
+module_exit(mtd_devdata_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alban Bedel <albeu@free.fr>");
+MODULE_DESCRIPTION("Driver to read device data from MTD devices");
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 3/3] ath9k: ahb: Add OF support
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
2017-02-27 20:28 ` [PATCH 1/3] " Alban
2017-02-27 20:28 ` [PATCH 2/3] mtd: Add support for reading device data out of MTD devices Alban
@ 2017-02-27 20:28 ` Alban
2017-02-27 21:13 ` Rafał Miłecki
2017-02-28 18:03 ` kbuild test robot
2017-02-27 20:42 ` [RFC 0/3] drivers: Add an API to read device specific config data Boris Brezillon
2017-02-27 20:42 ` Marek Vasut
4 siblings, 2 replies; 13+ messages in thread
From: Alban @ 2017-02-27 20:28 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mtd, Cyrille Pitchen, Richard Weinberger, Marek Vasut,
Boris Brezillon, Brian Norris, David Woodhouse,
Greg Kroah-Hartman, Alban Bedel
From: Alban Bedel <albeu@free.fr>
Allow registering ath9k AHB devices defined in OF. The binding
currently only allow to set the MAC address and to optionally
disable the 2GHz or 5GHz band. The EEPROM data is loaded using
the device data API.
Signed-off-by: Alban Bedel <albeu@free.fr>
---
drivers/net/wireless/ath/ath9k/Kconfig | 1 +
drivers/net/wireless/ath/ath9k/ahb.c | 55 +++++++++++++++++++++++++++++-----
drivers/net/wireless/ath/ath9k/init.c | 41 ++++++++++++++++++++++++-
3 files changed, 89 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f..5d459f7 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -49,6 +49,7 @@ config ATH9K_PCI
config ATH9K_AHB
bool "Atheros ath9k AHB bus support"
depends on ATH9K
+ select DEVDATA
default n
---help---
This option enables the AHB bus support in ath9k.
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 2bd982c..5aaaa16 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -18,6 +18,9 @@
#include <linux/nl80211.h>
#include <linux/platform_device.h>
+#include <linux/devdata.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
#include <linux/module.h>
#include "ath9k.h"
@@ -49,6 +52,33 @@ static const struct platform_device_id ath9k_platform_id_table[] = {
{},
};
+#ifdef CONFIG_OF
+static const struct of_device_id ath_ahb_of_match[] = {
+ {
+ .compatible = "qca,ar9100-wmac",
+ .data = (void *)AR5416_AR9100_DEVID
+ },
+ {
+ .compatible = "qca,ar9330-wmac",
+ .data = (void *)AR9300_DEVID_AR9330
+ },
+ {
+ .compatible = "qca,ar9340-wmac",
+ .data = (void *)AR9300_DEVID_AR9340
+ },
+ {
+ .compatible = "qca,qca9550-wmac",
+ .data = (void *)AR9300_DEVID_QCA955X
+ },
+ {
+ .compatible = "qca,qca9530-wmac",
+ .data = (void *)AR9300_DEVID_AR953X
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ath_ahb_of_match);
+#endif
+
/* return bus cachesize in 4B word units */
static void ath_ahb_read_cachesize(struct ath_common *common, int *csz)
{
@@ -57,9 +87,9 @@ static void ath_ahb_read_cachesize(struct ath_common *common, int *csz)
static bool ath_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
{
- ath_err(common, "%s: eeprom data has to be provided externally\n",
- __func__);
- return false;
+ struct ath_softc *sc = (struct ath_softc *)common->priv;
+
+ return !devdata_read(sc->dev, "eeprom", off * 2, data, 2);
}
static const struct ath_bus_ops ath_ahb_bus_ops = {
@@ -79,10 +109,20 @@ static int ath_ahb_probe(struct platform_device *pdev)
int ret = 0;
struct ath_hw *ah;
char hw_name[64];
+ u16 devid;
- if (!dev_get_platdata(&pdev->dev)) {
- dev_err(&pdev->dev, "no platform data specified\n");
- return -EINVAL;
+ if (id) {
+ devid = id->driver_data;
+ } else {
+ const struct of_device_id *match;
+
+ match = of_match_device(ath_ahb_of_match, &pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "no device match found\n");
+ return -EINVAL;
+ }
+
+ devid = (u16)(unsigned long)match->data;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -127,7 +167,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
goto err_free_hw;
}
- ret = ath9k_init_device(id->driver_data, sc, &ath_ahb_bus_ops);
+ ret = ath9k_init_device(devid, sc, &ath_ahb_bus_ops);
if (ret) {
dev_err(&pdev->dev, "failed to initialize device\n");
goto err_irq;
@@ -167,6 +207,7 @@ static struct platform_driver ath_ahb_driver = {
.remove = ath_ahb_remove,
.driver = {
.name = "ath9k",
+ .of_match_table = of_match_ptr(ath_ahb_of_match),
},
.id_table = ath9k_platform_id_table,
};
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index fa4b3cc..21194e5 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -23,6 +23,8 @@
#include <linux/of.h>
#include <linux/of_net.h>
#include <linux/relay.h>
+#include <linux/clk.h>
+#include <linux/of_net.h>
#include <net/ieee80211_radiotap.h>
#include "ath9k.h"
@@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
release_firmware(sc->sc_ah->eeprom_blob);
}
+#ifdef CONFIG_OF
+static int ath9k_init_of(struct ath_softc *sc)
+{
+ struct device_node *np = sc->dev->of_node;
+ struct ath_hw *ah = sc->sc_ah;
+ const void *macaddr;
+ struct clk *clk;
+ int ret = 0;
+
+ if (!np) {
+ dev_err(sc->dev, "no platform data or OF node\n");
+ return -EINVAL;
+ }
+
+ clk = clk_get(sc->dev, "ref");
+ if (!IS_ERR(clk)) {
+ ah->is_clk_25mhz = (clk_get_rate(clk) == 25000000);
+ clk_put(clk);
+ }
+
+ ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
+ ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
+
+ macaddr = of_get_mac_address(np);
+ if (macaddr)
+ memcpy(ath9k_hw_common(ah)->macaddr, macaddr, ETH_ALEN);
+
+ return ret;
+}
+#else
+static int ath9k_init_of(struct ath_softc *sc)
+{
+ dev_err(sc->dev, "no platform data\n");
+ return -EINVAL;
+}
+#endif
+
static int ath9k_init_platform(struct ath_softc *sc)
{
struct ath9k_platform_data *pdata = sc->dev->platform_data;
@@ -521,7 +560,7 @@ static int ath9k_init_platform(struct ath_softc *sc)
int ret;
if (!pdata)
- return 0;
+ return ath9k_init_of(sc);
if (!pdata->use_eeprom) {
ah->ah_flags &= ~AH_USE_EEPROM;
--
2.7.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 3/3] ath9k: ahb: Add OF support
2017-02-27 20:28 ` [PATCH 3/3] ath9k: ahb: Add OF support Alban
@ 2017-02-27 21:13 ` Rafał Miłecki
2017-02-27 22:48 ` Alban
2017-02-28 18:03 ` kbuild test robot
1 sibling, 1 reply; 13+ messages in thread
From: Rafał Miłecki @ 2017-02-27 21:13 UTC (permalink / raw)
To: Alban
Cc: Linux Kernel Mailing List, Boris Brezillon, Richard Weinberger,
Marek Vasut, linux-mtd, Greg Kroah-Hartman, Cyrille Pitchen,
Brian Norris, David Woodhouse, linux-wireless
Why you didn't cc linux-wireless?!?!
On 27 February 2017 at 21:28, Alban <albeu@free.fr> wrote:
> @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> release_firmware(sc->sc_ah->eeprom_blob);
> }
>
> +#ifdef CONFIG_OF
> +static int ath9k_init_of(struct ath_softc *sc)
> +{
> + struct device_node *np = sc->dev->of_node;
> + struct ath_hw *ah = sc->sc_ah;
> + const void *macaddr;
> + struct clk *clk;
> + int ret = 0;
> +
> + if (!np) {
> + dev_err(sc->dev, "no platform data or OF node\n");
> + return -EINVAL;
> + }
> +
> + clk = clk_get(sc->dev, "ref");
> + if (!IS_ERR(clk)) {
> + ah->is_clk_25mhz = (clk_get_rate(clk) == 25000000);
> + clk_put(clk);
> + }
> +
> + ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> + ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
Please use ieee80211-freq-limit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896
Most likely with the wiphy_read_of_freq_limits helper:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17
Example:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 3/3] ath9k: ahb: Add OF support
2017-02-27 21:13 ` Rafał Miłecki
@ 2017-02-27 22:48 ` Alban
2017-02-27 22:54 ` Rafał Miłecki
0 siblings, 1 reply; 13+ messages in thread
From: Alban @ 2017-02-27 22:48 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Aban Bedel, Linux Kernel Mailing List, Boris Brezillon,
Richard Weinberger, Marek Vasut, linux-mtd, Greg Kroah-Hartman,
Cyrille Pitchen, Brian Norris, David Woodhouse, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]
On Mon, 27 Feb 2017 22:13:21 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> Why you didn't cc linux-wireless?!?!
I first wanted to be sure that the devdata part was generally
acceptable, this patch was just included as an example of a user.
But it sound like that part will have to move to nvmem first.
I'll come back with a new patch once MTD support for nvmem is
done.
> On 27 February 2017 at 21:28, Alban <albeu@free.fr> wrote:
> > @@ -513,6 +515,43 @@ static void ath9k_eeprom_release(struct ath_softc *sc)
> > release_firmware(sc->sc_ah->eeprom_blob);
> > }
> >
> > +#ifdef CONFIG_OF
> > +static int ath9k_init_of(struct ath_softc *sc)
> > +{
> > + struct device_node *np = sc->dev->of_node;
> > + struct ath_hw *ah = sc->sc_ah;
> > + const void *macaddr;
> > + struct clk *clk;
> > + int ret = 0;
> > +
> > + if (!np) {
> > + dev_err(sc->dev, "no platform data or OF node\n");
> > + return -EINVAL;
> > + }
> > +
> > + clk = clk_get(sc->dev, "ref");
> > + if (!IS_ERR(clk)) {
> > + ah->is_clk_25mhz = (clk_get_rate(clk) == 25000000);
> > + clk_put(clk);
> > + }
> > +
> > + ah->disable_2ghz = of_property_read_bool(np, "qca,disable-2ghz");
> > + ah->disable_5ghz = of_property_read_bool(np, "qca,disable-5ghz");
>
> Please use ieee80211-freq-limit:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b330b25eaabda00d74e47566d9200907da381896
>
> Most likely with the wiphy_read_of_freq_limits helper:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e691ac2f75b69bee743f0370d79454ba4429b17
>
> Example:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f83ff69735651cc7a3d150466a5257ff829b62b
Thanks, I'll check this.
Alban
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 3/3] ath9k: ahb: Add OF support
2017-02-27 22:48 ` Alban
@ 2017-02-27 22:54 ` Rafał Miłecki
0 siblings, 0 replies; 13+ messages in thread
From: Rafał Miłecki @ 2017-02-27 22:54 UTC (permalink / raw)
To: Alban
Cc: Linux Kernel Mailing List, Boris Brezillon, Richard Weinberger,
Marek Vasut, linux-mtd, Greg Kroah-Hartman, Cyrille Pitchen,
Brian Norris, David Woodhouse, linux-wireless
On 27 February 2017 at 23:48, Alban <albeu@free.fr> wrote:
> On Mon, 27 Feb 2017 22:13:21 +0100
> Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wrote:
>
>> Why you didn't cc linux-wireless?!?!
>
> I first wanted to be sure that the devdata part was generally
> acceptable, this patch was just included as an example of a user.
> But it sound like that part will have to move to nvmem first.
> I'll come back with a new patch once MTD support for nvmem is
> done.
OK, I just realized this was supposed to be RFC (for some reason this
patch didn't include RFC tag). At least this is was I assume to by
looking at the:
[RFC 0/3] drivers: Add an API to read device specific config data
Good luck!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] ath9k: ahb: Add OF support
@ 2017-02-27 22:54 ` Rafał Miłecki
0 siblings, 0 replies; 13+ messages in thread
From: Rafał Miłecki @ 2017-02-27 22:54 UTC (permalink / raw)
To: Alban
Cc: Linux Kernel Mailing List, Boris Brezillon, Richard Weinberger,
Marek Vasut, linux-mtd, Greg Kroah-Hartman, Cyrille Pitchen,
Brian Norris, David Woodhouse, linux-wireless
On 27 February 2017 at 23:48, Alban <albeu@free.fr> wrote:
> On Mon, 27 Feb 2017 22:13:21 +0100
> Rafał Miłecki <zajec5@gmail.com> wrote:
>
>> Why you didn't cc linux-wireless?!?!
>
> I first wanted to be sure that the devdata part was generally
> acceptable, this patch was just included as an example of a user.
> But it sound like that part will have to move to nvmem first.
> I'll come back with a new patch once MTD support for nvmem is
> done.
OK, I just realized this was supposed to be RFC (for some reason this
patch didn't include RFC tag). At least this is was I assume to by
looking at the:
[RFC 0/3] drivers: Add an API to read device specific config data
Good luck!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/3] ath9k: ahb: Add OF support
2017-02-27 20:28 ` [PATCH 3/3] ath9k: ahb: Add OF support Alban
2017-02-27 21:13 ` Rafał Miłecki
@ 2017-02-28 18:03 ` kbuild test robot
1 sibling, 0 replies; 13+ messages in thread
From: kbuild test robot @ 2017-02-28 18:03 UTC (permalink / raw)
To: Alban
Cc: kbuild-all, linux-kernel, linux-mtd, Cyrille Pitchen,
Richard Weinberger, Marek Vasut, Boris Brezillon, Brian Norris,
David Woodhouse, Greg Kroah-Hartman, Alban Bedel
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]
Hi Alban,
[auto build test ERROR on mtd/master]
[also build test ERROR on v4.10 next-20170228]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alban/drivers-Add-an-API-to-read-device-specific-config-data/20170228-202937
base: git://git.infradead.org/linux-mtd.git master
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "devdata_read" [drivers/net/wireless/ath/ath9k/ath9k.ko] undefined!
>> ERROR: "devm_devdata_provider_register" [drivers/mtd/devdata.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 60480 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC 0/3] drivers: Add an API to read device specific config data
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
` (2 preceding siblings ...)
2017-02-27 20:28 ` [PATCH 3/3] ath9k: ahb: Add OF support Alban
@ 2017-02-27 20:42 ` Boris Brezillon
2017-02-27 22:26 ` Moritz Fischer
2017-02-27 22:41 ` Alban
2017-02-27 20:42 ` Marek Vasut
4 siblings, 2 replies; 13+ messages in thread
From: Boris Brezillon @ 2017-02-27 20:42 UTC (permalink / raw)
To: Alban
Cc: linux-kernel, linux-mtd, Cyrille Pitchen, Richard Weinberger,
Marek Vasut, Brian Norris, David Woodhouse, Greg Kroah-Hartman,
Moritz Fischer
+Moritz
Hi Alban,
On Mon, 27 Feb 2017 21:28:09 +0100
Alban <albeu@free.fr> wrote:
> Hi all,
>
> while looking at adding OF support for the ath9k driver I had the problem of
> reading the EEPROM data. On the SoC platforms this data is stored in an SPI
> flash along with a few other things. In OpenWRT/LEDE this data is read from
> the board init code using the fact that the flash is (normaly) readable from
> a memory map. A bit too hackish for my taste.
>
> This is just one example, there is various other similar cases, mostly with
> MAC addresses. I thought it would be nicer if we had a clean API for this,
> similar to the firmware API but per device instance instead of beeing per
> driver. The device driver wouldn't have to care where the data is stored,
> they just request it and the backend take care of reading the EEPROM, MTD
> or whatever is used on the board.
>
> This series implement such an API along with an implementation for MTD
> devices and a use in the ath9k driver. As this is an RFC I didn't yet
> write the OF binding documentation, that will come later if the feedback
> is positive.
What you're looking for already exists and it's called nvmem[1]. Some
work has been done to expose MTD partitions as nvmem cells [2], but
it's never been finished.
Can you please finish Moritz implementation instead of creating a new
API?
Thanks,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/nvmem/nvmem.txt
[2]https://patchwork.ozlabs.org/patch/626460/
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [RFC 0/3] drivers: Add an API to read device specific config data
2017-02-27 20:42 ` [RFC 0/3] drivers: Add an API to read device specific config data Boris Brezillon
@ 2017-02-27 22:26 ` Moritz Fischer
2017-02-27 22:41 ` Alban
1 sibling, 0 replies; 13+ messages in thread
From: Moritz Fischer @ 2017-02-27 22:26 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alban, Linux Kernel Mailing List, linux-mtd, Cyrille Pitchen,
Richard Weinberger, Marek Vasut, Brian Norris, David Woodhouse,
Greg Kroah-Hartman
Hi all,
On Mon, Feb 27, 2017 at 12:42 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> +Moritz
>
> Hi Alban,
>
> On Mon, 27 Feb 2017 21:28:09 +0100
> Alban <albeu@free.fr> wrote:
>
>> Hi all,
>>
>> while looking at adding OF support for the ath9k driver I had the problem of
>> reading the EEPROM data. On the SoC platforms this data is stored in an SPI
>> flash along with a few other things. In OpenWRT/LEDE this data is read from
>> the board init code using the fact that the flash is (normaly) readable from
>> a memory map. A bit too hackish for my taste.
>>
>> This is just one example, there is various other similar cases, mostly with
>> MAC addresses. I thought it would be nicer if we had a clean API for this,
>> similar to the firmware API but per device instance instead of beeing per
>> driver. The device driver wouldn't have to care where the data is stored,
>> they just request it and the backend take care of reading the EEPROM, MTD
>> or whatever is used on the board.
>>
>> This series implement such an API along with an implementation for MTD
>> devices and a use in the ath9k driver. As this is an RFC I didn't yet
>> write the OF binding documentation, that will come later if the feedback
>> is positive.
>
> What you're looking for already exists and it's called nvmem[1]. Some
> work has been done to expose MTD partitions as nvmem cells [2], but
> it's never been finished.
> Can you please finish Moritz implementation instead of creating a new
> API?
Whoops ... this totally fell off my radar (project got axed for $REASONS).
I could potentially take another look at this this weekend, otherwise I'm
happy to review whatever you come up with Alban.
Cheers,
Moritz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC 0/3] drivers: Add an API to read device specific config data
2017-02-27 20:42 ` [RFC 0/3] drivers: Add an API to read device specific config data Boris Brezillon
2017-02-27 22:26 ` Moritz Fischer
@ 2017-02-27 22:41 ` Alban
1 sibling, 0 replies; 13+ messages in thread
From: Alban @ 2017-02-27 22:41 UTC (permalink / raw)
To: Boris Brezillon
Cc: Aban Bedel, linux-kernel, linux-mtd, Cyrille Pitchen,
Richard Weinberger, Marek Vasut, Brian Norris, David Woodhouse,
Greg Kroah-Hartman, Moritz Fischer
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Mon, 27 Feb 2017 21:42:30 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> +Moritz
>
> Hi Alban,
>
> On Mon, 27 Feb 2017 21:28:09 +0100
> Alban <albeu@free.fr> wrote:
>
> > Hi all,
> >
> > while looking at adding OF support for the ath9k driver I had the problem of
> > reading the EEPROM data. On the SoC platforms this data is stored in an SPI
> > flash along with a few other things. In OpenWRT/LEDE this data is read from
> > the board init code using the fact that the flash is (normaly) readable from
> > a memory map. A bit too hackish for my taste.
> >
> > This is just one example, there is various other similar cases, mostly with
> > MAC addresses. I thought it would be nicer if we had a clean API for this,
> > similar to the firmware API but per device instance instead of beeing per
> > driver. The device driver wouldn't have to care where the data is stored,
> > they just request it and the backend take care of reading the EEPROM, MTD
> > or whatever is used on the board.
> >
> > This series implement such an API along with an implementation for MTD
> > devices and a use in the ath9k driver. As this is an RFC I didn't yet
> > write the OF binding documentation, that will come later if the feedback
> > is positive.
>
> What you're looking for already exists and it's called nvmem[1]. Some
> work has been done to expose MTD partitions as nvmem cells [2], but
> it's never been finished.
> Can you please finish Moritz implementation instead of creating a new
> API?
I didn't knew about the nvmem API :/ I'll look into finishing the MTD
support then.
Alban
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC 0/3] drivers: Add an API to read device specific config data
2017-02-27 20:28 [RFC 0/3] drivers: Add an API to read device specific config data Alban
` (3 preceding siblings ...)
2017-02-27 20:42 ` [RFC 0/3] drivers: Add an API to read device specific config data Boris Brezillon
@ 2017-02-27 20:42 ` Marek Vasut
4 siblings, 0 replies; 13+ messages in thread
From: Marek Vasut @ 2017-02-27 20:42 UTC (permalink / raw)
To: Alban, linux-kernel
Cc: linux-mtd, Cyrille Pitchen, Richard Weinberger, Boris Brezillon,
Brian Norris, David Woodhouse, Greg Kroah-Hartman
On 02/27/2017 09:28 PM, Alban wrote:
> Hi all,
>
> while looking at adding OF support for the ath9k driver I had the problem of
> reading the EEPROM data. On the SoC platforms this data is stored in an SPI
> flash along with a few other things. In OpenWRT/LEDE this data is read from
> the board init code using the fact that the flash is (normaly) readable from
> a memory map. A bit too hackish for my taste.
>
> This is just one example, there is various other similar cases, mostly with
> MAC addresses. I thought it would be nicer if we had a clean API for this,
> similar to the firmware API but per device instance instead of beeing per
> driver. The device driver wouldn't have to care where the data is stored,
> they just request it and the backend take care of reading the EEPROM, MTD
> or whatever is used on the board.
Can't we use the NVMEM for this stuff ?
> This series implement such an API along with an implementation for MTD
> devices and a use in the ath9k driver. As this is an RFC I didn't yet
> write the OF binding documentation, that will come later if the feedback
> is positive.
>
> Alban Bedel (3):
> drivers: Add an API to read device specific config data
> mtd: Add support for reading device data out of MTD devices
> ath9k: ahb: Add OF support
>
> drivers/base/Kconfig | 6 +
> drivers/base/Makefile | 1 +
> drivers/base/devdata.c | 204 +++++++++++++++++++++++++++++++++
> drivers/mtd/Kconfig | 9 ++
> drivers/mtd/Makefile | 1 +
> drivers/mtd/devdata.c | 70 +++++++++++
> drivers/net/wireless/ath/ath9k/Kconfig | 1 +
> drivers/net/wireless/ath/ath9k/ahb.c | 55 +++++++--
> drivers/net/wireless/ath/ath9k/init.c | 41 ++++++-
> include/linux/devdata.h | 79 +++++++++++++
> 10 files changed, 459 insertions(+), 8 deletions(-)
> create mode 100644 drivers/base/devdata.c
> create mode 100644 drivers/mtd/devdata.c
> create mode 100644 include/linux/devdata.h
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 13+ messages in thread