* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Jeremy Allison @ 2015-03-30 20:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeremy Allison, Christoph Hellwig, Milosz Tanski, linux-kernel,
linux-fsdevel, linux-aio, Mel Gorman, Volker Lendecke, Tejun Heo,
Jeff Moyer, Theodore Ts'o, Al Viro, linux-api,
Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330133758.d2788f6de72f121170ff0301@linux-foundation.org>
On Mon, Mar 30, 2015 at 01:37:58PM -0700, Andrew Morton wrote:
> On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison <jra@samba.org> wrote:
>
> > On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote:
> > >
> > > cons:
> > >
> > > d) fincore() is more expensive
> > >
> > > e) fincore() will very occasionally block
> >
> > The above is the killer for Samba. If fincore
> > returns true but when we schedule the pread
> > we block, we're hosed.
> >
> > Once we block, we're done serving clients on the main
> > thread until this returns. That can cause unpredictable
> > response times which can cause client timeouts.
> >
> > A fincore+pread solution that blocks is simply unsafe
> > to use for us. We'll have to stay with the threadpool :-(.
>
> Finally. Thanks ;)
>
> This implies that the samba main thread also has to avoid any memory
> allocations both direct and within syscall and pagefault - those will
> occasionally exhibit similar worse-case latency. Is this done now?
We don't do anything special around allocations in syscall.
For aio read we do talloc (internal memory allocator) the
return chunk before going into the pthread pread, so I
suppose this could block. Haven't seen this as a reported
problem though. I suppose you can say "well exactly the
same thing is true of fincore()" :-).
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Andrew Morton @ 2015-03-30 21:33 UTC (permalink / raw)
To: Jeremy Allison
Cc: Christoph Hellwig, Milosz Tanski, linux-kernel, linux-fsdevel,
linux-aio, Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, linux-api, Michael Kerrisk,
linux-arch, Dave Chinner
In-Reply-To: <20150330204937.GB4987@samba2>
On Mon, 30 Mar 2015 13:49:37 -0700 Jeremy Allison <jra@samba.org> wrote:
> > This implies that the samba main thread also has to avoid any memory
> > allocations both direct and within syscall and pagefault - those will
> > occasionally exhibit similar worse-case latency. Is this done now?
>
> We don't do anything special around allocations in syscall.
> For aio read we do talloc (internal memory allocator) the
> return chunk before going into the pthread pread, so I
> suppose this could block. Haven't seen this as a reported
> problem though. I suppose you can say "well exactly the
> same thing is true of fincore()" :-).
yup. If we tickle the page's referenced bit in fincore() then the race
will only happen under the most withering memory loads, and it sounds
like the main thread will be suffering allocation stalls before that
point anyway.
^ permalink raw reply
* [PATCH v4 00/10] Add simple EEPROM Framework via regmap.
From: Srinivas Kandagatla @ 2015-03-30 21:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427236116-18531-1-git-send-email-srinivas.kandagatla@linaro.org>
Thankyou all for providing inputs and comments on previous versions of this patchset.
Here is the v4 of the patchset addressing all the issues raised as
part of previous versions review.
This patchset adds a new simple EEPROM framework to kernel.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
patch 1-2 Introduces two regmap helper functions.
patch 3-5 Introduces the EEPROM framework.
Patch 6 Adds helper functions for eeproms based on mmio.
Patch 7 migrates an existing driver to eeprom framework.
Patch 8-9 Adds Qualcomm specific qfprom driver.
Patch 10 adds entry in MAINTAINERS.
Its also possible to migrate other eeprom drivers to this framework.
Providers APIs:
eeprom_register/unregister();
Consumers APIs:
eeprom_cell_get()/of_eeprom_cell_get();
eeprom_cell_put();
eeprom_cell_read()/eeprom_cell_write();
Device Tree:
/* Provider */
qfprom: qfprom@00700000 {
compatible = "qcom,qfprom";
reg = <0x00700000 0x1000>;
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};
serial_number: sn {
reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
};
...
};
/* Consumer node */
tsens: tsens {
...
calibration = <&tsens_calibration>;
...
};
userspace interface: binary file in /sys/class/eeprom/*/eeprom
ex:
hexdump /sys/class/eeprom/qfprom0/eeprom
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00
0000000 0000 0000 0000 0000 0000 0000 0000 0000
...
*
0001000
Changes since v3(https://lkml.org/lkml/2015/3/24/1066)
* simplified logic in bin_attr_eeprom_read/write spotted by Mark Brown.
* moved from using regmap_bulk_read/write to regmap_raw_read/write
spotted by Mark Brown
* Fixed return error codes for the dummy wrappers spotted by Sascha Hauer
* Fixed various error code checks in core spotted by Sascha Hauer.
* Simplified consumer bindings suggested by Sascha Hauer.
* Added eeprom-mmio helper functions.
Changes since v2(https://lkml.org/lkml/2015/3/13/168)
* Fixed error handling in eeprom_register spotted by Mark Brown
* Added new regmap_get_max_register() and regmap_get_reg_stride().
* Fixed module build errors reported by kbuild robot.
* recycle the ids when eeprom provider is released.
Changes since v1(https://lkml.org/lkml/2015/3/5/153)
* Fix various Licencing issues spotted by Paul Bolle and Mark Brown
* Allow eeprom core to build as module spotted by Paul Bolle.
* Fix various kconfig issues spotted by Paul Bolle.
* remove unessary atomic varible spotted by Mark Brown.
* Few cleanups and common up some of the code in core.
* Add qfprom bindings.
Changes since RFC(https://lkml.org/lkml/2015/2/19/307)
* Fix documentation and error checks in read/write spotted by Andrew Lunn
* Kconfig fix suggested by Stephen Boyd.
* Add module owner suggested by Stephen Boyd and others.
* Fix unsafe handling of eeprom in unregister spotted by Russell and Mark Brown.
* seperate bindings patch as suggested by Rob.
* Add MAINTAINERS as suggested by Rob.
* Added support to allow reading eeprom for things like serial number which
* canbe scatters across.
* Added eeprom data using reg property suggested by Sascha and Stephen.
* Added non-DT support.
* Move kerneldoc to the src files spotted by Mark Brown.
* Remove local list and do eeprom lookup by using class_find_device()
Thanks,
srini
Maxime Ripard (1):
eeprom: sunxi: Move the SID driver to the eeprom framework
Srinivas Kandagatla (9):
regmap: Introduce regmap_get_max_register.
regmap: Introduce regmap_get_reg_stride.
eeprom: Add a simple EEPROM framework for eeprom providers
eeprom: Add a simple EEPROM framework for eeprom consumers
eeprom: Add bindings for simple eeprom framework
eeprom: Add simple eeprom-mmio consumer helper functions.
eeprom: qfprom: Add Qualcomm QFPROM support.
eeprom: qfprom: Add bindings for qfprom
eeprom: Add to MAINTAINERS for eeprom framework
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 -
.../bindings/eeprom/allwinner,sunxi-sid.txt | 21 +
.../devicetree/bindings/eeprom/eeprom.txt | 58 +++
.../devicetree/bindings/eeprom/qfprom.txt | 34 ++
.../bindings/misc/allwinner,sunxi-sid.txt | 17 -
MAINTAINERS | 9 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/base/regmap/regmap.c | 24 +
drivers/eeprom/Kconfig | 36 ++
drivers/eeprom/Makefile | 13 +
drivers/eeprom/core.c | 504 +++++++++++++++++++++
drivers/eeprom/eeprom-mmio.c | 69 +++
drivers/eeprom/eeprom-mmio.h | 41 ++
drivers/eeprom/qfprom.c | 51 +++
drivers/eeprom/sunxi-sid.c | 64 +++
drivers/misc/eeprom/Kconfig | 13 -
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c | 156 -------
include/linux/eeprom-consumer.h | 61 +++
include/linux/eeprom-provider.h | 43 ++
include/linux/regmap.h | 14 +
22 files changed, 1045 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
create mode 100644 Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
delete mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644 drivers/eeprom/Kconfig
create mode 100644 drivers/eeprom/Makefile
create mode 100644 drivers/eeprom/core.c
create mode 100644 drivers/eeprom/eeprom-mmio.c
create mode 100644 drivers/eeprom/eeprom-mmio.h
create mode 100644 drivers/eeprom/qfprom.c
create mode 100644 drivers/eeprom/sunxi-sid.c
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
create mode 100644 include/linux/eeprom-consumer.h
create mode 100644 include/linux/eeprom-provider.h
--
1.9.1
^ permalink raw reply
* [PATCH v4 01/10] regmap: Introduce regmap_get_max_register.
From: Srinivas Kandagatla @ 2015-03-30 21:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/base/regmap/regmap.c | 12 ++++++++++++
include/linux/regmap.h | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index f99b098..d703921 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2617,6 +2617,18 @@ int regmap_get_val_bytes(struct regmap *map)
}
EXPORT_SYMBOL_GPL(regmap_get_val_bytes);
+/**
+ * regmap_get_max_register(): Report the max register value
+ *
+ * Report the max register value, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_max_register(struct regmap *map)
+{
+ return map->max_register ? : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regmap_get_max_register);
+
int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
{
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 116655d..2d87ded 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -433,6 +433,7 @@ int regmap_update_bits_check_async(struct regmap *map, unsigned int reg,
unsigned int mask, unsigned int val,
bool *change);
int regmap_get_val_bytes(struct regmap *map);
+int regmap_get_max_register(struct regmap *map);
int regmap_async_complete(struct regmap *map);
bool regmap_can_raw_write(struct regmap *map);
@@ -676,6 +677,12 @@ static inline int regmap_get_val_bytes(struct regmap *map)
return -EINVAL;
}
+static inline int regmap_get_max_register(struct regmap *map)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline int regcache_sync(struct regmap *map)
{
WARN_ONCE(1, "regmap API is disabled");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 02/10] regmap: Introduce regmap_get_reg_stride.
From: Srinivas Kandagatla @ 2015-03-30 21:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like eeprom framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/base/regmap/regmap.c | 12 ++++++++++++
include/linux/regmap.h | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index d703921..ac44d43 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2629,6 +2629,18 @@ int regmap_get_max_register(struct regmap *map)
}
EXPORT_SYMBOL_GPL(regmap_get_max_register);
+/**
+ * regmap_get_reg_stride(): Report the register address stride
+ *
+ * Report the register address stride, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_reg_stride(struct regmap *map)
+{
+ return map->reg_stride;
+}
+EXPORT_SYMBOL_GPL(regmap_get_reg_stride);
+
int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
{
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 2d87ded..59c55ea 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -434,6 +434,7 @@ int regmap_update_bits_check_async(struct regmap *map, unsigned int reg,
bool *change);
int regmap_get_val_bytes(struct regmap *map);
int regmap_get_max_register(struct regmap *map);
+int regmap_get_reg_stride(struct regmap *map);
int regmap_async_complete(struct regmap *map);
bool regmap_can_raw_write(struct regmap *map);
@@ -683,6 +684,12 @@ static inline int regmap_get_max_register(struct regmap *map)
return -EINVAL;
}
+static inline int regmap_get_reg_stride(struct regmap *map)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline int regcache_sync(struct regmap *map)
{
WARN_ONCE(1, "regmap API is disabled");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 03/10] eeprom: Add a simple EEPROM framework for eeprom providers
From: Srinivas Kandagatla @ 2015-03-30 21:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds just providers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/eeprom/Kconfig | 10 ++
drivers/eeprom/Makefile | 6 ++
drivers/eeprom/core.c | 233 ++++++++++++++++++++++++++++++++++++++++
include/linux/eeprom-provider.h | 43 ++++++++
6 files changed, 295 insertions(+)
create mode 100644 drivers/eeprom/Kconfig
create mode 100644 drivers/eeprom/Makefile
create mode 100644 drivers/eeprom/core.c
create mode 100644 include/linux/eeprom-provider.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 7d233c1..6767a2f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -184,4 +184,6 @@ source "drivers/thunderbolt/Kconfig"
source "drivers/android/Kconfig"
+source "drivers/eeprom/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..57eb5b0 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT) += coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_EEPROM) += eeprom/
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
new file mode 100644
index 0000000..15985e1
--- /dev/null
+++ b/drivers/eeprom/Kconfig
@@ -0,0 +1,10 @@
+menuconfig EEPROM
+ tristate "EEPROM Support"
+ select REGMAP
+ help
+ Support for EEPROM alike devices.
+
+ This framework is designed to provide a generic interface to EEPROM
+ from both the Linux Kernel and the userspace.
+
+ If unsure, say no.
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
new file mode 100644
index 0000000..51a727f
--- /dev/null
+++ b/drivers/eeprom/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for eeprom drivers.
+#
+
+obj-$(CONFIG_EEPROM) += eeprom_core.o
+eeprom_core-y := core.o
diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
new file mode 100644
index 0000000..a2c7e6c
--- /dev/null
+++ b/drivers/eeprom/core.c
@@ -0,0 +1,233 @@
+/*
+ * EEPROM framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/eeprom-provider.h>
+#include <linux/export.h>
+#include <linux/fs.h>
+#include <linux/idr.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+struct eeprom_device {
+ struct regmap *regmap;
+ int stride;
+ int word_size;
+ size_t size;
+
+ struct module *owner;
+ struct device dev;
+ int id;
+ int users;
+};
+
+static DEFINE_MUTEX(eeprom_mutex);
+static DEFINE_IDA(eeprom_ida);
+
+#define to_eeprom(d) container_of(d, struct eeprom_device, dev)
+
+static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t pos, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct eeprom_device *eeprom = to_eeprom(dev);
+ int rc;
+
+ /* Stop the user from reading */
+ if (pos > eeprom->size)
+ return 0;
+
+ if (pos + count > eeprom->size)
+ count = eeprom->size - pos;
+
+ count = count/eeprom->word_size * eeprom->word_size;
+
+ rc = regmap_raw_read(eeprom->regmap, pos, buf, count);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return count;
+}
+
+static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t pos, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct eeprom_device *eeprom = to_eeprom(dev);
+ int rc;
+
+ /* Stop the user from writing */
+ if (pos > eeprom->size)
+ return 0;
+
+ if (pos + count > eeprom->size)
+ count = eeprom->size - pos;
+
+ count = count/eeprom->word_size * eeprom->word_size;
+
+ rc = regmap_raw_write(eeprom->regmap, pos, buf, count);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return count;
+}
+
+static struct bin_attribute bin_attr_eeprom = {
+ .attr = {
+ .name = "eeprom",
+ .mode = S_IWUSR | S_IRUGO,
+ },
+ .read = bin_attr_eeprom_read,
+ .write = bin_attr_eeprom_write,
+};
+
+static struct bin_attribute *eeprom_bin_attributes[] = {
+ &bin_attr_eeprom,
+ NULL,
+};
+
+static const struct attribute_group eeprom_bin_group = {
+ .bin_attrs = eeprom_bin_attributes,
+};
+
+static const struct attribute_group *eeprom_dev_groups[] = {
+ &eeprom_bin_group,
+ NULL,
+};
+
+static void eeprom_release(struct device *dev)
+{
+ struct eeprom_device *eeprom = to_eeprom(dev);
+
+ ida_simple_remove(&eeprom_ida, eeprom->id);
+ kfree(eeprom);
+}
+
+static struct class eeprom_class = {
+ .name = "eeprom",
+ .dev_groups = eeprom_dev_groups,
+ .dev_release = eeprom_release,
+};
+
+/**
+ * eeprom_register(): Register a eeprom device for given eeprom.
+ * Also creates an binary entry in /sys/class/eeprom/name-id/eeprom
+ *
+ * @eeprom: eeprom device that needs to be created
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to eeprom_device.
+ */
+
+struct eeprom_device *eeprom_register(struct eeprom_config *config)
+{
+ struct eeprom_device *eeprom;
+ struct regmap *rm;
+ int rval;
+
+ if (!config->dev)
+ return ERR_PTR(-EINVAL);
+
+ rm = dev_get_regmap(config->dev, NULL);
+ if (!rm) {
+ dev_err(config->dev, "Regmap not found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ eeprom = kzalloc(sizeof(*eeprom), GFP_KERNEL);
+ if (!eeprom)
+ return ERR_PTR(-ENOMEM);
+
+ eeprom->id = ida_simple_get(&eeprom_ida, 0, 0, GFP_KERNEL);
+ if (eeprom->id < 0) {
+ kfree(eeprom);
+ return ERR_PTR(eeprom->id);
+ }
+
+ eeprom->regmap = rm;
+ eeprom->owner = config->owner;
+ eeprom->stride = regmap_get_reg_stride(rm);
+ eeprom->word_size = regmap_get_val_bytes(rm);
+ eeprom->size = regmap_get_max_register(rm) + eeprom->stride;
+ eeprom->dev.class = &eeprom_class;
+ eeprom->dev.parent = config->dev;
+ eeprom->dev.of_node = config->dev ? config->dev->of_node : NULL;
+ dev_set_name(&eeprom->dev, "%s%d",
+ config->name ? : "eeprom", config->id);
+
+ device_initialize(&eeprom->dev);
+
+ dev_dbg(&eeprom->dev, "Registering eeprom device %s\n",
+ dev_name(&eeprom->dev));
+
+ rval = device_add(&eeprom->dev);
+ if (rval) {
+ ida_simple_remove(&eeprom_ida, eeprom->id);
+ kfree(eeprom);
+ return ERR_PTR(rval);
+ }
+
+ return eeprom;
+}
+EXPORT_SYMBOL_GPL(eeprom_register);
+
+/**
+ * eeprom_unregister(): Unregister previously registered eeprom device
+ *
+ * @eeprom: Pointer to previously registered eeprom device.
+ *
+ * The return value will be an non zero on error or a zero on success.
+ */
+int eeprom_unregister(struct eeprom_device *eeprom)
+{
+ mutex_lock(&eeprom_mutex);
+ if (eeprom->users) {
+ mutex_unlock(&eeprom_mutex);
+ return -EBUSY;
+ }
+ mutex_unlock(&eeprom_mutex);
+
+ device_del(&eeprom->dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(eeprom_unregister);
+
+static int eeprom_init(void)
+{
+ return class_register(&eeprom_class);
+}
+
+static void eeprom_exit(void)
+{
+ class_unregister(&eeprom_class);
+}
+
+subsys_initcall(eeprom_init);
+module_exit(eeprom_exit);
+
+MODULE_AUTHOR("Srinivas Kandagatla <srinivas.kandagatla@linaro.org");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com");
+MODULE_DESCRIPTION("EEPROM Driver Core");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/eeprom-provider.h b/include/linux/eeprom-provider.h
new file mode 100644
index 0000000..1892897
--- /dev/null
+++ b/include/linux/eeprom-provider.h
@@ -0,0 +1,43 @@
+/*
+ * EEPROM framework provider.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_EEPROM_PROVIDER_H
+#define _LINUX_EEPROM_PROVIDER_H
+
+struct eeprom_device;
+
+struct eeprom_config {
+ struct device *dev;
+ const char *name;
+ int id;
+ struct module *owner;
+};
+
+#if IS_ENABLED(CONFIG_EEPROM)
+
+struct eeprom_device *eeprom_register(struct eeprom_config *cfg);
+int eeprom_unregister(struct eeprom_device *eeprom);
+
+#else
+
+static inline struct eeprom_device *eeprom_register(struct eeprom_config *cfg)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline int eeprom_unregister(struct eeprom_device *eeprom)
+{
+ return -ENOSYS;
+}
+
+#endif /* CONFIG_EEPROM */
+
+#endif /* ifndef _LINUX_EEPROM_PROVIDER_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers
From: Srinivas Kandagatla @ 2015-03-30 21:57 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds just consumers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/eeprom/core.c | 271 ++++++++++++++++++++++++++++++++++++++++
include/linux/eeprom-consumer.h | 61 +++++++++
2 files changed, 332 insertions(+)
create mode 100644 include/linux/eeprom-consumer.h
diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
index a2c7e6c..7065275 100644
--- a/drivers/eeprom/core.c
+++ b/drivers/eeprom/core.c
@@ -16,6 +16,7 @@
#include <linux/device.h>
#include <linux/eeprom-provider.h>
+#include <linux/eeprom-consumer.h>
#include <linux/export.h>
#include <linux/fs.h>
#include <linux/idr.h>
@@ -38,6 +39,13 @@ struct eeprom_device {
int users;
};
+struct eeprom_cell {
+ struct eeprom_device *eeprom;
+ int nblocks;
+ int size;
+ struct eeprom_block blocks[0];
+};
+
static DEFINE_MUTEX(eeprom_mutex);
static DEFINE_IDA(eeprom_ida);
@@ -130,6 +138,37 @@ static struct class eeprom_class = {
.dev_release = eeprom_release,
};
+static int of_eeprom_match(struct device *dev, const void *eeprom_np)
+{
+ return dev->of_node == eeprom_np;
+}
+
+static struct eeprom_device *of_eeprom_find(struct device_node *eeprom_np)
+{
+ struct device *d;
+
+ if (!eeprom_np)
+ return NULL;
+
+ d = class_find_device(&eeprom_class, NULL, eeprom_np, of_eeprom_match);
+
+ return d ? to_eeprom(d) : NULL;
+}
+
+static int eeprom_match(struct device *dev, const void *data)
+{
+ return !strcmp(dev_name(dev), (const char *)data);
+}
+
+static struct eeprom_device *eeprom_find(const char *name)
+{
+ struct device *d;
+
+ d = class_find_device(&eeprom_class, NULL, (void *)name, eeprom_match);
+
+ return d ? to_eeprom(d) : NULL;
+}
+
/**
* eeprom_register(): Register a eeprom device for given eeprom.
* Also creates an binary entry in /sys/class/eeprom/name-id/eeprom
@@ -214,6 +253,238 @@ int eeprom_unregister(struct eeprom_device *eeprom)
}
EXPORT_SYMBOL_GPL(eeprom_unregister);
+static int eeprom_cell_sanity_check(struct eeprom_cell *cell)
+{
+ struct eeprom_device *eeprom = cell->eeprom;
+ int i;
+
+ /* byte aligned, no need to check for stride sanity */
+ if (eeprom->stride == 1)
+ return 0;
+
+ for (i = 0; i < cell->nblocks; i++) {
+ if (!IS_ALIGNED(cell->blocks[i].offset, eeprom->stride)) {
+ dev_err(&eeprom->dev,
+ "cell unaligned to eeprom stride %d\n",
+ eeprom->stride);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static struct eeprom_cell *__eeprom_cell_get(struct device_node *cell_np,
+ const char *ename,
+ struct eeprom_block *blocks,
+ int nblocks)
+{
+ struct eeprom_cell *cell;
+ struct eeprom_device *eeprom;
+ struct property *prop;
+ const __be32 *vp;
+ u32 pv;
+ int i, rval;
+
+ mutex_lock(&eeprom_mutex);
+
+ eeprom = cell_np ? of_eeprom_find(cell_np->parent) : eeprom_find(ename);
+ if (!eeprom) {
+ mutex_unlock(&eeprom_mutex);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ eeprom->users++;
+ mutex_unlock(&eeprom_mutex);
+
+ if (!try_module_get(eeprom->owner)) {
+ dev_err(&eeprom->dev,
+ "could not increase module refcount for cell %s\n",
+ ename);
+ rval = -EINVAL;
+ goto err_mod;
+ }
+
+ if (cell_np)
+ nblocks = of_property_count_u32_elems(cell_np, "reg") / 2;
+
+ cell = kzalloc(sizeof(*cell) + nblocks * sizeof(*blocks), GFP_KERNEL);
+ if (!cell) {
+ rval = -ENOMEM;
+ goto err_mem;
+ }
+
+ cell->nblocks = nblocks;
+ cell->eeprom = eeprom;
+ cell->size = 0;
+ i = 0;
+
+ if (cell_np) {
+ of_property_for_each_u32(cell_np, "reg", prop, vp, pv) {
+ cell->blocks[i].offset = pv;
+ vp = of_prop_next_u32(prop, vp, &pv);
+ cell->blocks[i].count = pv;
+ cell->size += pv;
+ i++;
+ }
+ } else {
+ memcpy(cell->blocks, blocks, nblocks * sizeof(*blocks));
+ for (; i < nblocks; i++)
+ cell->size += blocks[i].count;
+ }
+
+ if (IS_ERR_VALUE(eeprom_cell_sanity_check(cell))) {
+ rval = -EINVAL;
+ goto err_sanity;
+ }
+
+ return cell;
+
+err_sanity:
+ kfree(cell);
+
+err_mem:
+ module_put(eeprom->owner);
+
+err_mod:
+ mutex_lock(&eeprom_mutex);
+ eeprom->users--;
+ mutex_unlock(&eeprom_mutex);
+
+ return ERR_PTR(rval);
+
+}
+
+/**
+ * eeprom_cell_get(): Get eeprom cell of device form a given eeprom name
+ * and blocks.
+ *
+ * @ename: eeprom device name that needs to be looked-up.
+ * @blocks: eeprom blocks containing offset and length information.
+ * @nblocks: number of eeprom blocks.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct eeprom_cell. The eeprom_cell will be freed by the
+ * eeprom_cell_put().
+ */
+struct eeprom_cell *eeprom_cell_get(const char *ename,
+ struct eeprom_block *blocks, int nblocks)
+{
+ return __eeprom_cell_get(NULL, ename, blocks, nblocks);
+}
+EXPORT_SYMBOL_GPL(eeprom_cell_get);
+
+/**
+ * of_eeprom_cell_get(): Get eeprom cell of device form a given index
+ *
+ * @dev node: Device tree node that uses the eeprom cell
+ * @index: eeprom index in eeproms property.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct eeprom_cell. The eeprom_cell will be freed by the
+ * eeprom_cell_put().
+ */
+struct eeprom_cell *of_eeprom_cell_get(struct device_node *np, const char *name)
+{
+ struct device_node *cell_np;
+
+ cell_np = of_parse_phandle(np, name, 0);
+ if (!cell_np)
+ return ERR_PTR(-EINVAL);
+
+ return __eeprom_cell_get(cell_np, NULL, NULL, 0);
+}
+EXPORT_SYMBOL_GPL(of_eeprom_cell_get);
+
+/**
+ * eeprom_cell_put(): Release previously allocated eeprom cell.
+ *
+ * @cell: Previously allocated eeprom cell by eeprom_cell_get()
+ * or of_eeprom_cell_get().
+ */
+void eeprom_cell_put(struct eeprom_cell *cell)
+{
+ struct eeprom_device *eeprom = cell->eeprom;
+
+ mutex_lock(&eeprom_mutex);
+ eeprom->users--;
+ mutex_unlock(&eeprom_mutex);
+ module_put(eeprom->owner);
+ kfree(cell);
+}
+EXPORT_SYMBOL_GPL(eeprom_cell_put);
+
+/**
+ * eeprom_cell_read(): Read a given eeprom cell
+ *
+ * @cell: eeprom cell to be read.
+ * @len: pointer to length of cell which will be populated on successful read.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a char * bufffer. The buffer should be freed by the consumer with a
+ * kfree().
+ */
+char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len)
+{
+ struct eeprom_device *eeprom = cell->eeprom;
+ char *buf;
+ int rc, i, offset = 0;
+
+ if (!eeprom || !eeprom->regmap)
+ return ERR_PTR(-EINVAL);
+
+ buf = kzalloc(cell->size, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < cell->nblocks; i++) {
+ rc = regmap_raw_read(eeprom->regmap, cell->blocks[i].offset,
+ buf + offset, cell->blocks[i].count);
+
+ if (IS_ERR_VALUE(rc)) {
+ kfree(buf);
+ return ERR_PTR(rc);
+ }
+ offset += cell->blocks[i].count;
+ }
+
+ *len = cell->size;
+
+ return buf;
+}
+EXPORT_SYMBOL_GPL(eeprom_cell_read);
+
+/**
+ * eeprom_cell_write(): Write to a given eeprom cell
+ *
+ * @cell: eeprom cell to be written.
+ * @buf: Buffer to be written.
+ * @len: length of buffer to be written to eeprom cell.
+ *
+ * The return value will be an length of bytes written or non zero on failure.
+ */
+int eeprom_cell_write(struct eeprom_cell *cell, const char *buf, ssize_t len)
+{
+ struct eeprom_device *eeprom = cell->eeprom;
+ int i, rc, offset = 0;
+
+ if (!eeprom || !eeprom->regmap || len != cell->size)
+ return -EINVAL;
+
+ for (i = 0; i < cell->nblocks; i++) {
+ rc = regmap_raw_write(eeprom->regmap, cell->blocks[i].offset,
+ buf + offset, cell->blocks[i].count);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ offset += cell->blocks[i].count;
+ }
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(eeprom_cell_write);
+
static int eeprom_init(void)
{
return class_register(&eeprom_class);
diff --git a/include/linux/eeprom-consumer.h b/include/linux/eeprom-consumer.h
new file mode 100644
index 0000000..effa417
--- /dev/null
+++ b/include/linux/eeprom-consumer.h
@@ -0,0 +1,61 @@
+/*
+ * EEPROM framework consumer.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_EEPROM_CONSUMER_H
+#define _LINUX_EEPROM_CONSUMER_H
+
+struct eeprom_cell;
+
+struct eeprom_block {
+ loff_t offset;
+ size_t count;
+};
+#if IS_ENABLED(CONFIG_EEPROM)
+struct eeprom_cell *eeprom_cell_get(const char *ename,
+ struct eeprom_block *blocks, int nblocks);
+void eeprom_cell_put(struct eeprom_cell *cell);
+char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len);
+int eeprom_cell_write(struct eeprom_cell *cell, const char *buf, ssize_t len);
+#else
+
+static inline struct eeprom_cell *eeprom_cell_get(const char *ename,
+ struct eeprom_block *blocks, int nblocks)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline void eeprom_cell_put(struct eeprom_cell *cell)
+{
+}
+
+static inline char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline int eeprom_cell_write(struct eeprom_cell *cell,
+ const char *buf, ssize_t len)
+{
+ return -ENOSYS;
+}
+#endif /* CONFIG_EEPROM */
+
+#if IS_ENABLED(CONFIG_EEPROM) && IS_ENABLED(CONFIG_OF)
+struct eeprom_cell *of_eeprom_cell_get(struct device_node *dev,
+ const char *property);
+#else
+static inline struct eeprom_cell *of_eeprom_cell_get(struct device_node *np,
+ const char *property)
+{
+ return ERR_PTR(-ENOSYS);
+}
+#endif
+#endif /* ifndef _LINUX_EEPROM_CONSUMER_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
From: Srinivas Kandagatla @ 2015-03-30 21:57 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/eeprom/eeprom.txt | 58 ++++++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 0000000..fb71d46
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,58 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg: specifies the offset in byte within that storage device, and the length
+ in bytes of the data we care about.
+ There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@00700000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00700000 0x8000>;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@4404 {
+ reg = <0x4404 0x10>;
+ };
+
+ serial_number: sn {
+ reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+For example:
+
+ tsens {
+ ...
+ calibration = <&tsens_calibration>;
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v4 06/10] eeprom: Add simple eeprom-mmio consumer helper functions.
From: Srinivas Kandagatla @ 2015-03-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds probe and remove helper functions for eeproms which are
mmio based, With these helper function new eeprom consumer drivers need
very little code add its driver.
This code is currently used for qfprom and sunxi-sid eeprom consumer drivers.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/eeprom/Makefile | 1 +
drivers/eeprom/eeprom-mmio.c | 69 ++++++++++++++++++++++++++++++++++++++++++++
drivers/eeprom/eeprom-mmio.h | 41 ++++++++++++++++++++++++++
3 files changed, 111 insertions(+)
create mode 100644 drivers/eeprom/eeprom-mmio.c
create mode 100644 drivers/eeprom/eeprom-mmio.h
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
index 51a727f..6812bbe 100644
--- a/drivers/eeprom/Makefile
+++ b/drivers/eeprom/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_EEPROM) += eeprom_core.o
eeprom_core-y := core.o
+eeprom_core-y += eeprom-mmio.o
diff --git a/drivers/eeprom/eeprom-mmio.c b/drivers/eeprom/eeprom-mmio.c
new file mode 100644
index 0000000..55b8913
--- /dev/null
+++ b/drivers/eeprom/eeprom-mmio.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include "eeprom-mmio.h"
+
+int eeprom_mmio_remove(struct platform_device *pdev)
+{
+ struct eeprom_device *eeprom = platform_get_drvdata(pdev);
+
+ return eeprom_unregister(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_mmio_remove);
+
+int eeprom_mmio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ const struct eeprom_mmio_data *data;
+ struct eeprom_device *eeprom;
+ struct regmap *regmap;
+ const struct of_device_id *match;
+ void __iomem *base;
+
+ if (!dev || !dev->driver)
+ return -ENODEV;
+
+ match = of_match_device(dev->driver->of_match_table, dev);
+ if (!match || !match->data)
+ return -EINVAL;
+
+ data = match->data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ data->regmap_config->max_register = resource_size(res) - 1;
+
+ regmap = devm_regmap_init_mmio(dev, base, data->regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(regmap);
+ }
+ data->eeprom_config->dev = dev;
+ eeprom = eeprom_register(data->eeprom_config);
+ if (IS_ERR(eeprom))
+ return PTR_ERR(eeprom);
+
+ platform_set_drvdata(pdev, eeprom);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(eeprom_mmio_probe);
diff --git a/drivers/eeprom/eeprom-mmio.h b/drivers/eeprom/eeprom-mmio.h
new file mode 100644
index 0000000..e58bcc8
--- /dev/null
+++ b/drivers/eeprom/eeprom-mmio.h
@@ -0,0 +1,41 @@
+/*
+ * MMIO based EEPROM providers.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_EEPROM_MMIO_H
+#define _LINUX_EEPROM_MMIO_H
+
+#include <linux/platform_device.h>
+#include <linux/eeprom-provider.h>
+#include <linux/regmap.h>
+
+struct eeprom_mmio_data {
+ struct regmap_config *regmap_config;
+ struct eeprom_config *eeprom_config;
+};
+
+#if IS_ENABLED(CONFIG_EEPROM)
+
+int eeprom_mmio_probe(struct platform_device *pdev);
+int eeprom_mmio_remove(struct platform_device *pdev);
+
+#else
+
+static inline int eeprom_mmio_probe(struct platform_device *pdev)
+{
+ return -ENOSYS;
+}
+
+static inline int eeprom_mmio_remove(struct platform_device *pdev)
+{
+ return -ENOSYS;
+}
+#endif
+
+#endif /* ifndef _LINUX_EEPROM_MMIO_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v4 07/10] eeprom: qfprom: Add Qualcomm QFPROM support.
From: Srinivas Kandagatla @ 2015-03-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/eeprom/Kconfig | 15 +++++++++++++++
drivers/eeprom/Makefile | 4 ++++
drivers/eeprom/qfprom.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 70 insertions(+)
create mode 100644 drivers/eeprom/qfprom.c
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index 15985e1..8fcde9b 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -8,3 +8,18 @@ menuconfig EEPROM
from both the Linux Kernel and the userspace.
If unsure, say no.
+
+if EEPROM
+
+config QCOM_QFPROM
+ tristate "QCOM QFPROM Support"
+ depends on ARCH_QCOM
+ select REGMAP_MMIO
+ help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via eeprom interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called eeprom-qfprom.
+
+endif
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
index 6812bbe..819476c 100644
--- a/drivers/eeprom/Makefile
+++ b/drivers/eeprom/Makefile
@@ -5,3 +5,7 @@
obj-$(CONFIG_EEPROM) += eeprom_core.o
eeprom_core-y := core.o
eeprom_core-y += eeprom-mmio.o
+
+# Devices
+obj-$(CONFIG_QCOM_QFPROM) += eeprom_qfprom.o
+eeprom_qfprom-y := qfprom.o
diff --git a/drivers/eeprom/qfprom.c b/drivers/eeprom/qfprom.c
new file mode 100644
index 0000000..011bdf1
--- /dev/null
+++ b/drivers/eeprom/qfprom.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include "eeprom-mmio.h"
+
+static struct regmap_config qfprom_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .reg_stride = 1,
+};
+
+static struct eeprom_config econfig = {
+ .name = "qfprom",
+ .owner = THIS_MODULE,
+};
+
+static struct eeprom_mmio_data qfprom_data = {
+ .eeprom_config = &econfig,
+ .regmap_config = &qfprom_regmap_config,
+};
+
+static const struct of_device_id qfprom_of_match[] = {
+ { .compatible = "qcom,qfprom", .data = &qfprom_data},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+ .probe = eeprom_mmio_probe,
+ .remove = eeprom_mmio_remove,
+ .driver = {
+ .name = "qcom,qfprom",
+ .of_match_table = qfprom_of_match,
+ },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR("Srinivas Kandagatla <srinivas.kandagatla@linaro.org>");
+MODULE_DESCRIPTION("Qualcomm QFPROM driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 08/10] eeprom: qfprom: Add bindings for qfprom
From: Srinivas Kandagatla @ 2015-03-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple eeprom framework.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
.../devicetree/bindings/eeprom/qfprom.txt | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt b/Documentation/devicetree/bindings/eeprom/qfprom.txt
new file mode 100644
index 0000000..21a7104
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
@@ -0,0 +1,34 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example:
+
+ qfprom: qfprom@00700000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00700000 0x8000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x4404 0x10>;
+ };
+ };
+
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+For example:
+
+ tsens {
+ ...
+ calibration = <&tsens_calibration>;
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v4 09/10] eeprom: sunxi: Move the SID driver to the eeprom framework
From: Srinivas Kandagatla @ 2015-03-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Now that we have the EEPROM framework, we can consolidate the common driver
code. Move the driver to the framework, and hopefully, it will fix the sysfs
file creation race.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
.../bindings/eeprom/allwinner,sunxi-sid.txt | 21 +++
.../bindings/misc/allwinner,sunxi-sid.txt | 17 ---
drivers/eeprom/Kconfig | 11 ++
drivers/eeprom/Makefile | 2 +
drivers/eeprom/sunxi-sid.c | 64 +++++++++
drivers/misc/eeprom/Kconfig | 13 --
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c | 156 ---------------------
9 files changed, 98 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
create mode 100644 Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
delete mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644 drivers/eeprom/sunxi-sid.c
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..0000000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What: /sys/devices/*/<our-device>/eeprom
-Date: August 2013
-Contact: Oliver Schinagl <oliver@schinagl.nl>
-Description: read-only access to the SID (Security-ID) on current
- A-series SoC's from Allwinner. Currently supports A10, A10s, A13
- and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
- whereas the newer A20 SoC exposes 512 bytes split into sections.
- Besides the 16 bytes of SID, there's also an SJTAG area,
- HDMI-HDCP key and some custom keys. Below a quick overview, for
- details see the user manual:
- 0x000 128 bit root-key (sun[457]i)
- 0x010 128 bit boot-key (sun7i)
- 0x020 64 bit security-jtag-key (sun7i)
- 0x028 16 bit key configuration (sun7i)
- 0x02b 16 bit custom-vendor-key (sun7i)
- 0x02c 320 bit low general key (sun7i)
- 0x040 32 bit read-control access (sun7i)
- 0x064 224 bit low general key (sun7i)
- 0x080 2304 bit HDCP-key (sun7i)
- 0x1a0 768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
- Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
new file mode 100644
index 0000000..cceaaf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example for sun4i:
+ sid@01c23800 {
+ compatible = "allwinner,sun4i-a10-sid";
+ reg = <0x01c23800 0x10>
+ };
+
+Example for sun7i:
+ sid@01c23800 {
+ compatible = "allwinner,sun7i-a20-sid";
+ reg = <0x01c23800 0x200>
+ };
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..0000000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
-- reg: Should contain registers location and length
-
-Example for sun4i:
- sid@01c23800 {
- compatible = "allwinner,sun4i-a10-sid";
- reg = <0x01c23800 0x10>
- };
-
-Example for sun7i:
- sid@01c23800 {
- compatible = "allwinner,sun7i-a20-sid";
- reg = <0x01c23800 0x200>
- };
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index 8fcde9b..f931fcb 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -22,4 +22,15 @@ config QCOM_QFPROM
This driver can also be built as a module. If so, the module
will be called eeprom-qfprom.
+config EEPROM_SUNXI_SID
+ tristate "Allwinner SoCs SID support"
+ depends on ARCH_SUNXI
+ select REGMAP_MMIO
+ help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called eeprom-sunxi-sid.
+
endif
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
index 819476c..8bd9450 100644
--- a/drivers/eeprom/Makefile
+++ b/drivers/eeprom/Makefile
@@ -9,3 +9,5 @@ eeprom_core-y += eeprom-mmio.o
# Devices
obj-$(CONFIG_QCOM_QFPROM) += eeprom_qfprom.o
eeprom_qfprom-y := qfprom.o
+obj-$(CONFIG_EEPROM_SUNXI_SID) += eeprom-sunxi-sid.o
+eeprom-sunxi-sid-y := sunxi-sid.o
diff --git a/drivers/eeprom/sunxi-sid.c b/drivers/eeprom/sunxi-sid.c
new file mode 100644
index 0000000..b963463
--- /dev/null
+++ b/drivers/eeprom/sunxi-sid.c
@@ -0,0 +1,64 @@
+/*
+ * Allwinner sunXi SoCs Security ID support.
+ *
+ * Copyright (c) 2013 Oliver Schinagl <oliver@schinagl.nl>
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include "eeprom-mmio.h"
+
+static bool sunxi_sid_writeable_reg(struct device *dev, unsigned int reg)
+{
+ return false;
+}
+
+static struct eeprom_config econfig = {
+ .name = "sunix-sid",
+ .owner = THIS_MODULE,
+};
+
+static struct regmap_config sunxi_sid_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .writeable_reg = sunxi_sid_writeable_reg,
+};
+
+static struct eeprom_mmio_data sunxi_data = {
+ .eeprom_config = &econfig,
+ .regmap_config = &sunxi_sid_regmap_config,
+};
+
+static const struct of_device_id sunxi_sid_of_match[] = {
+ { .compatible = "allwinner,sun4i-a10-sid", .data = &sunxi_data},
+ { .compatible = "allwinner,sun7i-a20-sid", .data = &sunxi_data},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
+
+static struct platform_driver sunxi_sid_driver = {
+ .probe = eeprom_mmio_probe,
+ .remove = eeprom_mmio_remove,
+ .driver = {
+ .name = "eeprom-sunxi-sid",
+ .of_match_table = sunxi_sid_of_match,
+ },
+};
+module_platform_driver(sunxi_sid_driver);
+
+MODULE_AUTHOR("Oliver Schinagl <oliver@schinagl.nl>");
+MODULE_DESCRIPTION("Allwinner sunxi security id driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
If unsure, say N.
-config EEPROM_SUNXI_SID
- tristate "Allwinner sunxi security ID support"
- depends on ARCH_SUNXI && SYSFS
- help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing e-fuses,
- this driver is read-only.
-
- This driver can also be built as a module. If so, the module
- will be called sunxi_sid.
-
endmenu
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..fc1e81d 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -4,5 +4,4 @@ obj-$(CONFIG_EEPROM_LEGACY) += eeprom.o
obj-$(CONFIG_EEPROM_MAX6875) += max6875.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
obj-$(CONFIG_EEPROM_93XX46) += eeprom_93xx46.o
-obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
obj-$(CONFIG_EEPROM_DIGSY_MTC_CFG) += digsy_mtc_eeprom.o
diff --git a/drivers/misc/eeprom/sunxi_sid.c b/drivers/misc/eeprom/sunxi_sid.c
deleted file mode 100644
index 8385177..0000000
--- a/drivers/misc/eeprom/sunxi_sid.c
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * Copyright (c) 2013 Oliver Schinagl <oliver@schinagl.nl>
- * http://www.linux-sunxi.org
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * This driver exposes the Allwinner security ID, efuses exported in byte-
- * sized chunks.
- */
-
-#include <linux/compiler.h>
-#include <linux/device.h>
-#include <linux/err.h>
-#include <linux/export.h>
-#include <linux/fs.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/kobject.h>
-#include <linux/module.h>
-#include <linux/of_device.h>
-#include <linux/platform_device.h>
-#include <linux/random.h>
-#include <linux/slab.h>
-#include <linux/stat.h>
-#include <linux/sysfs.h>
-#include <linux/types.h>
-
-#define DRV_NAME "sunxi-sid"
-
-struct sunxi_sid_data {
- void __iomem *reg_base;
- unsigned int keysize;
-};
-
-/* We read the entire key, due to a 32 bit read alignment requirement. Since we
- * want to return the requested byte, this results in somewhat slower code and
- * uses 4 times more reads as needed but keeps code simpler. Since the SID is
- * only very rarely probed, this is not really an issue.
- */
-static u8 sunxi_sid_read_byte(const struct sunxi_sid_data *sid_data,
- const unsigned int offset)
-{
- u32 sid_key;
-
- if (offset >= sid_data->keysize)
- return 0;
-
- sid_key = ioread32be(sid_data->reg_base + round_down(offset, 4));
- sid_key >>= (offset % 4) * 8;
-
- return sid_key; /* Only return the last byte */
-}
-
-static ssize_t sid_read(struct file *fd, struct kobject *kobj,
- struct bin_attribute *attr, char *buf,
- loff_t pos, size_t size)
-{
- struct platform_device *pdev;
- struct sunxi_sid_data *sid_data;
- int i;
-
- pdev = to_platform_device(kobj_to_dev(kobj));
- sid_data = platform_get_drvdata(pdev);
-
- if (pos < 0 || pos >= sid_data->keysize)
- return 0;
- if (size > sid_data->keysize - pos)
- size = sid_data->keysize - pos;
-
- for (i = 0; i < size; i++)
- buf[i] = sunxi_sid_read_byte(sid_data, pos + i);
-
- return i;
-}
-
-static struct bin_attribute sid_bin_attr = {
- .attr = { .name = "eeprom", .mode = S_IRUGO, },
- .read = sid_read,
-};
-
-static int sunxi_sid_remove(struct platform_device *pdev)
-{
- device_remove_bin_file(&pdev->dev, &sid_bin_attr);
- dev_dbg(&pdev->dev, "driver unloaded\n");
-
- return 0;
-}
-
-static const struct of_device_id sunxi_sid_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-sid", .data = (void *)16},
- { .compatible = "allwinner,sun7i-a20-sid", .data = (void *)512},
- {/* sentinel */},
-};
-MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
-
-static int sunxi_sid_probe(struct platform_device *pdev)
-{
- struct sunxi_sid_data *sid_data;
- struct resource *res;
- const struct of_device_id *of_dev_id;
- u8 *entropy;
- unsigned int i;
-
- sid_data = devm_kzalloc(&pdev->dev, sizeof(struct sunxi_sid_data),
- GFP_KERNEL);
- if (!sid_data)
- return -ENOMEM;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sid_data->reg_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(sid_data->reg_base))
- return PTR_ERR(sid_data->reg_base);
-
- of_dev_id = of_match_device(sunxi_sid_of_match, &pdev->dev);
- if (!of_dev_id)
- return -ENODEV;
- sid_data->keysize = (int)of_dev_id->data;
-
- platform_set_drvdata(pdev, sid_data);
-
- sid_bin_attr.size = sid_data->keysize;
- if (device_create_bin_file(&pdev->dev, &sid_bin_attr))
- return -ENODEV;
-
- entropy = kzalloc(sizeof(u8) * sid_data->keysize, GFP_KERNEL);
- for (i = 0; i < sid_data->keysize; i++)
- entropy[i] = sunxi_sid_read_byte(sid_data, i);
- add_device_randomness(entropy, sid_data->keysize);
- kfree(entropy);
-
- dev_dbg(&pdev->dev, "loaded\n");
-
- return 0;
-}
-
-static struct platform_driver sunxi_sid_driver = {
- .probe = sunxi_sid_probe,
- .remove = sunxi_sid_remove,
- .driver = {
- .name = DRV_NAME,
- .of_match_table = sunxi_sid_of_match,
- },
-};
-module_platform_driver(sunxi_sid_driver);
-
-MODULE_AUTHOR("Oliver Schinagl <oliver@schinagl.nl>");
-MODULE_DESCRIPTION("Allwinner sunxi security id driver");
-MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 10/10] eeprom: Add to MAINTAINERS for eeprom framework
From: Srinivas Kandagatla @ 2015-03-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, Rob Herring, Kumar Gala, Mark Brown, s.hauer,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd, Srinivas Kandagatla
In-Reply-To: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds MAINTAINERS to eeprom framework.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 358eb01..7094bb0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3721,6 +3721,15 @@ T: git git://git.alsa-project.org/alsa-kernel.git
S: Maintained
F: sound/usb/misc/ua101.c
+EEPROM FRAMEWORK
+M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+M: Maxime Ripard <maxime.ripard@free-electrons.com>
+S: Maintained
+F: drivers/eeprom/
+F: Documentation/devicetree/bindings/eeprom/
+F: include/linux/eeprom-provider.h
+F: include/linux/eeprom-consumer.h
+
EXTENSIBLE FIRMWARE INTERFACE (EFI)
M: Matt Fleming <matt.fleming@intel.com>
L: linux-efi@vger.kernel.org
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 22:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeremy Allison, Christoph Hellwig, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330133758.d2788f6de72f121170ff0301@linux-foundation.org>
On Mon, Mar 30, 2015 at 4:37 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison <jra@samba.org> wrote:
>
>> On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote:
>> >
>> > cons:
>> >
>> > d) fincore() is more expensive
>> >
>> > e) fincore() will very occasionally block
>>
>> The above is the killer for Samba. If fincore
>> returns true but when we schedule the pread
>> we block, we're hosed.
>>
>> Once we block, we're done serving clients on the main
>> thread until this returns. That can cause unpredictable
>> response times which can cause client timeouts.
>>
>> A fincore+pread solution that blocks is simply unsafe
>> to use for us. We'll have to stay with the threadpool :-(.
>
> Finally. Thanks ;)
>
> This implies that the samba main thread also has to avoid any memory
> allocations both direct and within syscall and pagefault - those will
> occasionally exhibit similar worse-case latency. Is this done now?
>
>
It's entirely possible to have an application with a low / semi static
working set, and leave lots of free memory for the kernel especially
for the page cache. For example the Google want to minimize malloc().
So in tcmalloc() they grab large chunks and rarely release it to back
to the OS, in fact old version never shrank it. So you can entirely
avoid stalls in malloc() for many workloads.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 22:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, LKML, linux-fsdevel@vger.kernel.org,
linux-aio@kvack.org, Mel Gorman, Volker Lendecke, Tejun Heo,
Jeff Moyer, Theodore Ts'o, Al Viro, Linux API,
Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330115414.f7900c7062fe6370cb2aea8d@linux-foundation.org>
On Mon, Mar 30, 2015 at 2:54 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
>> > mm... I don't think we should be adding placeholders to the kernel API
>> > to support code which hasn't been written, tested, reviewed, merged,
>> > etc. It's possible none of this will ever happen and we end up with a
>> > syscall nobody needs or uses. Plus it's always possible that during
>> > this development we decide the pwrite2() interface needs alteration but
>> > it's too late.
>> >
>> > What would be the downside of deferring pwrite2() until it's all
>> > implemented?
>>
>> It _is_ implemented. I just decided to submit it separately as Miklos
>> already has to deal with enough bikeshedding for his feature that I
>> don't want to put the burden of dealing with the BS for the one I wrote
>> on him.
>
> afacit the only difference between this pwritev2() and the existing
> pwritev() is that pwritev2() interprets pos==-1 as "current position",
> which duplicates writev()?
>
> Unless I've missed something, there's no point in merging this
> pwritev2() and it would be better to separate this syscall out into a
> pwritev2() patchset which can be considered and merged separately. For
> the reasons described above.
>
At the LSF/MM session, the agreement form the active participants
(James Bottomley, Ted Tso, Christoph, and I forget the last guy's
name) that we should ship both syscalls in the first patch. Personally
I don't care, but you're the only voice against it.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 22:49 UTC (permalink / raw)
To: Jeremy Allison
Cc: Andrew Morton, Christoph Hellwig, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330203227.GA4987@samba2>
On Mon, Mar 30, 2015 at 4:32 PM, Jeremy Allison <jra@samba.org> wrote:
> On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote:
>>
>> cons:
>>
>> d) fincore() is more expensive
>>
>> e) fincore() will very occasionally block
>
> The above is the killer for Samba. If fincore
> returns true but when we schedule the pread
> we block, we're hosed.
>
> Once we block, we're done serving clients on the main
> thread until this returns. That can cause unpredictable
> response times which can cause client timeouts.
>
> A fincore+pread solution that blocks is simply unsafe
> to use for us. We'll have to stay with the threadpool :-(.
We're getting data from a network filesystem Ceph in our case, but it
could be pNFS. In many cases those filesystems have some kind
hierarchy and it's not uncommon for us to se requests that take 20 to
25 milliseconds to complete. In this case the miss becomes very
expensive. And it's not just that one requests experiences the slow
down all the request being serviced by that (single) epoll thread
experience head-of-line blocking because of one stalled request.
10K request a second is a common load for many web services / video
servers servings chunks of data. If we experience one miss a second,
that 25 million stall will impact 250 other requests (all of them will
have a 25ms latency tacked on).
>
>> And I don't believe that e) will be a problem in the real world. It's
>> a significant increase in worst-case latency and a negligible increase
>> in average latency. I've asked at least three times for someone to
>> explain why this is unacceptable and no explanation has been provided.
>
> See above.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Andrew Morton @ 2015-03-30 22:50 UTC (permalink / raw)
To: Milosz Tanski
Cc: Christoph Hellwig, LKML,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <CANP1eJH4BcZ0vgZ6pZdKOd4orEzfKUqjpKXb3m=WMy0mbK+PFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 30 Mar 2015 18:40:16 -0400 Milosz Tanski <milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Mar 30, 2015 at 2:54 PM, Andrew Morton
> <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > On Mon, 30 Mar 2015 00:40:20 -0700 Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> >
> >> On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
> >> > mm... I don't think we should be adding placeholders to the kernel API
> >> > to support code which hasn't been written, tested, reviewed, merged,
> >> > etc. It's possible none of this will ever happen and we end up with a
> >> > syscall nobody needs or uses. Plus it's always possible that during
> >> > this development we decide the pwrite2() interface needs alteration but
> >> > it's too late.
> >> >
> >> > What would be the downside of deferring pwrite2() until it's all
> >> > implemented?
> >>
> >> It _is_ implemented. I just decided to submit it separately as Miklos
> >> already has to deal with enough bikeshedding for his feature that I
> >> don't want to put the burden of dealing with the BS for the one I wrote
> >> on him.
> >
> > afacit the only difference between this pwritev2() and the existing
> > pwritev() is that pwritev2() interprets pos==-1 as "current position",
> > which duplicates writev()?
> >
> > Unless I've missed something, there's no point in merging this
> > pwritev2() and it would be better to separate this syscall out into a
> > pwritev2() patchset which can be considered and merged separately. For
> > the reasons described above.
> >
>
> At the LSF/MM session, the agreement form the active participants
> (James Bottomley, Ted Tso, Christoph, and I forget the last guy's
> name) that we should ship both syscalls in the first patch.
I was over in the mm session and probably wouldn't have objected either
because because you can't sit down, think, carefully inspect code and
evaluate arguments in such a context.
I've explained my reasoning. If there's something wrong with that
reasoning or if there are contradictory reasons which I'm not aware of
then let's hear them!
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 22:51 UTC (permalink / raw)
To: Jeremy Allison
Cc: Christoph Hellwig, Andrew Morton, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330171912.GB5835@samba2>
On Mon, Mar 30, 2015 at 1:19 PM, Jeremy Allison <jra@samba.org> wrote:
> On Mon, Mar 30, 2015 at 12:36:04AM -0700, Christoph Hellwig wrote:
>> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> > The problem with the above is that we can't tell the difference
>> > between pread2() returning a short read because the pages are not
>> > in cache, or because someone truncated the file. So we need some
>> > way to differentiate this.
>>
>> Is a race vs truncate really that time critical that you can't
>> wait for the thread pool to do the second read to notice it?
>
> Probably not, as this is the fallback path anyway.
>
>> > My preference from userspace would be for pread2() to return
>> > EAGAIN if *all* the data requested is not available (where
>> > 'all' can be less than the size requested if the file has
>> > been truncated in the meantime).
>>
>> That is easily implementable, but I can see that for example web apps
>> would be happy to get as much as possible. So if Samba can be ok
>> with short reads and only detecting the truncated case in the slow
>> path that would make life simpler. Otherwise we might indeed need two
>> flags.
>
> Simpler is better. I can live with the partial read+fallback.
>
> Jeremy.
The partial behavior is very useful for protocols like HTTP1, since
the client can start processing the response if we send it down the
wire while we process other connections. It becomes even more useful
over HTTP2 which provides it's own framing where we can send a partial
response frame and move onto other requests in this connection or
other connections.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Andrew Morton @ 2015-03-30 22:57 UTC (permalink / raw)
To: Milosz Tanski
Cc: Jeremy Allison, Christoph Hellwig, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <CANP1eJH5g0oWaLO0nD7XAcAO-rFHNTGUopF1aPLEifAbPnPOKQ@mail.gmail.com>
On Mon, 30 Mar 2015 18:49:06 -0400 Milosz Tanski <milosz@adfin.com> wrote:
> > A fincore+pread solution that blocks is simply unsafe
> > to use for us. We'll have to stay with the threadpool :-(.
>
> We're getting data from a network filesystem Ceph in our case, but it
> could be pNFS. In many cases those filesystems have some kind
> hierarchy and it's not uncommon for us to se requests that take 20 to
> 25 milliseconds to complete. In this case the miss becomes very
> expensive. And it's not just that one requests experiences the slow
> down all the request being serviced by that (single) epoll thread
> experience head-of-line blocking because of one stalled request.
>
> 10K request a second is a common load for many web services / video
> servers servings chunks of data. If we experience one miss a second,
> that 25 million stall will impact 250 other requests (all of them will
> have a 25ms latency tacked on).
I'd expect a fincore() which doesn't do SetPageReferenced() to be
orders of magnitude better than this. A fincore() which does use
SetPageReferenced() will be in the "basically never happens" region -
it would take massive and artificial memory stress to trigger.
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 23:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeremy Allison, Christoph Hellwig, LKML,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <20150330155700.92f4c8a0bf13418aaf01ae04-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Mon, Mar 30, 2015 at 6:57 PM, Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> On Mon, 30 Mar 2015 18:49:06 -0400 Milosz Tanski <milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org> wrote:
>
>> > A fincore+pread solution that blocks is simply unsafe
>> > to use for us. We'll have to stay with the threadpool :-(.
>>
>> We're getting data from a network filesystem Ceph in our case, but it
>> could be pNFS. In many cases those filesystems have some kind
>> hierarchy and it's not uncommon for us to se requests that take 20 to
>> 25 milliseconds to complete. In this case the miss becomes very
>> expensive. And it's not just that one requests experiences the slow
>> down all the request being serviced by that (single) epoll thread
>> experience head-of-line blocking because of one stalled request.
>>
>> 10K request a second is a common load for many web services / video
>> servers servings chunks of data. If we experience one miss a second,
>> that 25 million stall will impact 250 other requests (all of them will
>> have a 25ms latency tacked on).
>
> I'd expect a fincore() which doesn't do SetPageReferenced() to be
> orders of magnitude better than this. A fincore() which does use
> SetPageReferenced() will be in the "basically never happens" region -
> it would take massive and artificial memory stress to trigger.
I'm just responding to the upper bound you put out in an email a few
back of 0.0001% miss. And, people run web caches (like Apache Traffic
Server) at much higher rates than that.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz-B5zB6C1i6pkAvxtiuMwx3w@public.gmane.org
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 23:09 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jeremy Allison, Andrew Morton, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330073604.GB22229@infradead.org>
On Mon, Mar 30, 2015 at 3:36 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> The problem with the above is that we can't tell the difference
>> between pread2() returning a short read because the pages are not
>> in cache, or because someone truncated the file. So we need some
>> way to differentiate this.
>
> Is a race vs truncate really that time critical that you can't
> wait for the thread pool to do the second read to notice it?
>
>> My preference from userspace would be for pread2() to return
>> EAGAIN if *all* the data requested is not available (where
>> 'all' can be less than the size requested if the file has
>> been truncated in the meantime).
>
> That is easily implementable, but I can see that for example web apps
> would be happy to get as much as possible. So if Samba can be ok
> with short reads and only detecting the truncated case in the slow
> path that would make life simpler. Otherwise we might indeed need two
> flags.
I'm okay with an old or nothing flag. Although I think that would much
more useful with RWF_NONWAIT with pwritev, in applications that don't
want to block while logging (but it's okay to drop low level log
messages). That's a whole different use case in my mind.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-30 23:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Jeremy Allison, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150330132625.52b1250527ca3dcda79e349e@linux-foundation.org>
On Mon, Mar 30, 2015 at 4:26 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 30 Mar 2015 00:36:04 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
>> > The problem with the above is that we can't tell the difference
>> > between pread2() returning a short read because the pages are not
>> > in cache, or because someone truncated the file. So we need some
>> > way to differentiate this.
>>
>> Is a race vs truncate really that time critical that you can't
>> wait for the thread pool to do the second read to notice it?
>>
>> > My preference from userspace would be for pread2() to return
>> > EAGAIN if *all* the data requested is not available (where
>> > 'all' can be less than the size requested if the file has
>> > been truncated in the meantime).
>>
>> That is easily implementable, but I can see that for example web apps
>> would be happy to get as much as possible. So if Samba can be ok
>> with short reads and only detecting the truncated case in the slow
>> path that would make life simpler. Otherwise we might indeed need two
>> flags.
>
> The problem is that many applications (including samba!) want
> all-or-nothing behaviour, and preadv2() cannot provide it. By the time
> preadv2() discovers a not-present page, it has already copied bulk data
> out to userspace.
>
> To fix this, preadv2() would need to take two passes across the pages,
> pinning them in between and somehow blocking out truncate. That's a
> big change.
>
> With the current preadv2(), applications would have to do
>
> nr_read = preadv2(..., offset, len, ...);
> if (nr_read == len)
> process data;
> else
> punt(offset + nr_read, len - nr_read);
>
> and the worker thread will later have to splice together the initial
> data and the later-arriving data, probably on another CPU, probably
> after the initial data has gone cache-cold.
>
> A cleaner solution is
>
> if (fincore(fd, NULL, offset, len) == len) {
> preadv(..., offset, len);
> process data;
> } else {
> punt(offset, len);
> }
>
> This way all the data gets copied in a single hit and is cache-hot when
> userspace processes it.
>
> Comparing fincore()+pread() to preadv2():
>
> pros:
>
> a) fincore() may be used to provide both all-or-nothing and
> part-read-ok behaviour cleanly and with optimum cache behaviour.
>
> b) fincore() doesn't add overhead, complexity and stack depth to
> core pagecache read() code. Nor does it expand VFS data structures.
Actually, we're not expanding any VFS structures with the next
patchset. I've rebased the forthcoming patchset ontop of Al's
vfs/linux-next tree to keep track of the refactoring already done with
some of the code paths I touched. The refactoring work done there
already ads a flag argument to kiocb struct for other reasons.
>
> c) with a non-NULL second argument, fincore provides the
> mincore()-style page map.
>
> cons:
>
> d) fincore() is more expensive
>
> e) fincore() will very occasionally block
>
>
> Tradeoffs are involved. To decide on the best path we should examine
> d). I expect that the overhead will be significant for small reads but
> not significant for medium and large reads. Needs quantifying.
>
> And I don't believe that e) will be a problem in the real world. It's
> a significant increase in worst-case latency and a negligible increase
> in average latency. I've asked at least three times for someone to
> explain why this is unacceptable and no explanation has been provided.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Milosz Tanski @ 2015-03-31 1:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeremy Allison, Christoph Hellwig, LKML,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150327093046.53c2769a.akpm@linux-foundation.org>
On Fri, Mar 27, 2015 at 12:30 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 27 Mar 2015 08:58:54 -0700 Jeremy Allison <jra@samba.org> wrote:
>
>> On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote:
>> > On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>> >
>> > > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote:
>> > > > fincore() doesn't have to be ugly. Please address the design issues I
>> > > > raised. How is pread2() useful to the class of applications which
>> > > > cannot proceed until all data is available?
>> > >
>> > > It actually makes them work correctly? preadv2( ..., DONTWAIT) will
>> > > return -EGAIN, which causes them to bounce to the threadpool where
>> > > they call preadv(...).
>> >
>> > (I assume you mean RWF_NONBLOCK)
>> >
>> > That isn't how pread2() works. If the leading one or more pages are
>> > uptodate, pread2() will return a partial read. Now what? Either the
>> > application reads the same data a second time via the worker thread
>> > (dumb, but it will usually be a rare case)
>>
>> The problem with the above is that we can't tell the difference
>> between pread2() returning a short read because the pages are not
>> in cache, or because someone truncated the file. So we need some
>> way to differentiate this.
>>
>> My preference from userspace would be for pread2() to return
>> EAGAIN if *all* the data requested is not available (where
>> 'all' can be less than the size requested if the file has
>> been truncated in the meantime).
>>
>> ...
>>
>> The thing I want to avoid is the case where
>> ret < size_wanted means only part of the file
>> is in cache.
>
> From my reading of the code, pread2() will return -EAGAIN only when it
> copied zero bytes to userspace. ie, the very first page wasn't in
> cache. If pread2() does copy some data to userspace then it will
> return the amount of data copied. This is traditional read()
> behaviour.
>
> Maybe there's some other code somewhere in the patch which converts
> that short read into -EAGAIN, dunno - the changelogs don't appear to
> mention it and the manpage update is ambiguous about this.
>
> But from an interface perspective the behaviour you're asking for is
> insane, frankly - if the kernel copied out 8k of data then pread2()
> should return 8k. Otherwise there's no way for userspace to know that
> the 8k copy actually happened and we have just wasted a great pile of
> CPU doing a pointless memcpy.
>
> I expect that this situation (first part in cache, latter part not in
> cache) is rare - for reasonably small requests the common cases will be
> "all cached" and "nothing cached". So perhaps the best approach here
> is for samba to add special handling for the short read, to work out
> the reason for its occurrence.
>
> Alternatively we could add another flag to pread2() to select this
> "throw away my data and return -EAGAIN" behaviour. Presumably
> implemented with an i_size check, but it's gonna be racy.
>
>
>
> I take it from your comments that nobody has actually wired up pread2()
> into samba yet? That's a bit disturbing, because if we later want to
> go and change something like this short-read behaviour, we're screwed -
> it's a non back-compat userspace-visible change.
>
>
> And a note on cosmetics: why are we using EAGAIN here rather than
> EWOULDBLOCK? They have the same numerical value, but EWOULDBLOCK is a
> better name - EAGAIN says "run it again", but that won't work.
>
Per definition EWOULDBLOCK seams like a better fit. Like you said
above it won't stop blocking unless you do something. I also did a
search in the kernel source (excluding drivers / sound directories)
use of EAGAIN (even in network code) is like 2 magnitudes bigger then
EWOULDBLOCK. In fact some places that grep found check for both
(although I'm sure it's optimized out).
Does anybody feel strongly about it being EWOULDBLOCK instead of
EAGAIN? Esp. since they are same on Linux? The convention (by numbers)
seams to favor EAGAIN.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Rusty Russell @ 2015-03-31 1:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Carlos O'Donell,
Darren Hart, Ingo Molnar, Jakub Jelinek,
linux-man@vger.kernel.org, lkml, Davidlohr Bueso, Arnd Bergmann,
Steven Rostedt, Peter Zijlstra, Linux API, Torvald Riegel,
Roland McGrath, Darren Hart, Anton Blanchard
In-Reply-To: <55166C01.7000803-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
"Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> When executing a futex operation that requests to block a thread,
> the kernel will only block if the futex word has the value that the
> calling thread supplied as expected value.
> The load from the futex word, the comparison with
> the expected value,
> and the actual blocking will happen atomically and totally
> ordered with respect to concurrently executing futex operations
> on the same futex word,
> such as operations that wake threads blocked on this futex word.
> Thus, the futex word is used to connect the synchronization in user spac
Missing 'e' in "space".
> .\" FIXME Please confirm that the following is correct:
> No guarantee is provided about which waiters are awoken
> (e.g., a waiter with a higher scheduling priority is not guaranteed
> to be awoken in preference to a waiter with a lower priority).
This is true.
I didn't read the rest, as that stuff was all written by others.
Documenting them is pretty heroic; good job!
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 00/14] Add kdbus implementation
From: Andy Lutomirski @ 2015-03-31 13:58 UTC (permalink / raw)
To: David Herrmann
Cc: Greg Kroah-Hartman, Arnd Bergmann, Eric W. Biederman,
One Thousand Gnomes, Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Mack,
Djalal Harouni
In-Reply-To: <CANq1E4TTt3qanQse30KOZsuo2tfNoj7YSueh3AZ7bY1nQQeZNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Mar 30, 2015 at 9:56 AM, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi
>
> On Wed, Mar 25, 2015 at 7:12 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> On Wed, Mar 25, 2015 at 10:29 AM, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> [...]
>>>> I could be wrong about the lack of use cases. If so, please enlighten me.
>>>
>>> We have several dbus APIs that allow clients to register as a special
>>> handler/controller/etc. (eg., see systemd-logind TakeControl()). The
>>> API provider checks the privileges of a client on registration and
>>> then just tracks the client ID. This way, the client can be privileged
>>> when asking for special access, then drop privileges and still use the
>>> interface. You cannot re-connect in between, as the API provider
>>> tracks your bus ID. Without message-metadata, all your (other) calls
>>> on this bus would always be treated as privileged. We *really* want to
>>> avoid this.
>>
>> Connect twice?
>
> The remote peer might cache your connection ID to track you. You have
> to use the same connection to talk to that peer, in this given
> scenario. That's how D-Bus1 is used today, and we have to follow the
> semantics.
That's yet another reason that you really ought to disconnect and
reconnect after a privilege change -- the remote peer might remember
you.
The "might" will be a big problem. Users of kdbus can't rely on any
particular concept of privilege because you have too many of them.
>
>> You *already* have to reconnect or connect twice because you have
>> per-connection metadata. That's part of my problem with this scheme
>> -- you support *both styles*, which seems like it'll give you most of
>> the downsides of both without the upsides.
>
> Not necessarily. Connection metadata describes the state at the time
> you connected to the bus. If someone ask for this information, they
> will get exactly that. In this model, you cannot drop privileges, if
> you need to be privileged during setup.
> If someone asks for per-message metadata, they better ought not ask
> for per-connection creds. It's not the information they're looking
> for, so it will not match the data that at the time the message was
> sent.
>
> There is no immediate need to make both match. For security decisions,
> we mandate per-message creds. Per-connection creds are for
> backwards-compatibility to dbus1 and for passive introspection of bus
> connections.
Backwards compatibility doesn't magically exempt security
considerations. If new code is insecure when talking to a legacy
service, it's still insecure.
[...]
>> Again, you seem to be arguing that per-connection metadata is bad, but
>> you still have an implementation of per-connection metadata, so you
>> still have all these problems.
>
> I don't see why we get the problems of per-connection metadata. Just
> because you _can_ use it, doesn't mean you should use it for all
> imaginable use-cases. The same goes for reading information from
> /proc. There are valid use-cases to do so, but also a lot of cases
> where it will not provide the information you want.
>
Then you'll need to document really carefully which metadata is used
for which service. This actually seems impossible to do, since some
services will exist in legacy and kdbus forms.
>> I'm actually okay with per-message metadata in principle, but I'd like
>> to see evidence (with numbers, please) that a send+recv of per-message
>> metadata is *not* significantly slower than a recv of already-captured
>> per-connection metadata. If this is in fact the case, then maybe you
>> should trash per-connection metadata instead and the legacy
>> compatibility code can figure out a way to deal with it. IMO that
>> would be a pretty nice outcome, since you would never have to worry
>> whether your connection to the bus is inadvertantly privileged.
>
> Per-message metadata makes SEND about 25% slower, if you transmit the
> full set of all possible information. Just 3% if you only use
> PIDs+UIDs. The expensive metadata is cgroup-path and exe-path.
> If a service needs that information, however, and if that information
> is not guaranteed to be up-to-date, the service _will_ go and look it
> up in /proc or somewhere else, which is certainly a whole lot more
> expensive than the code in kdbus.
Can you give actual numbers, in ns or cycles, of how much overhead
metadata adds?
>
> In general, there seems to be a number of misconception in this thread
> about what kdbus is supposed to be. We're not inventing something new
> here with a clean slate, but we're moving parts of an existing
> implementation that has tons of users into the kernel, in order to fix
> issues that cannot be fixed otherwise in userspace (most notably, the
> race gaps that exist when retrieving per-message metadata). Therefore,
> we have to keep existing semantics stable, otherwise the exercise is
> somewhat pointless.
IOW you're taking something that you dislike aspects of and shoving
most of it in the kernel. That guarantees us an API in the kernel
that even the creators don't really like. This is, IMO, very
unfortunate.
Have you considered porting the kdbus per-message metadata mechanism to UDS?
--Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox