On Tuesday 05 January 2016 20:53:50 John Stultz wrote:
From: Greg Hackmann ghackmann@google.com
ramoops is one of the remaining places where ARM vendors still rely on board-specific shims. Device Tree lets us replace those shims with generic code.
These bindings mirror the ramoops module parameters, with two small differences:
(1) dump_oops becomes an optional "no-dump-oops" property, since ramoops sets dump_oops=1 by default.
The code has a "dump-oops" property, not "no-dump-oops".
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
There should also be a DT binding document that describes the valid properties.
@@ -450,15 +452,112 @@ void notrace ramoops_console_write_buf(const char *buf, size_t size) persistent_ram_write(cxt->cprz, buf, size); } +static int ramoops_parse_dt_size(struct platform_device *pdev,
const char *propname, unsigned long *val)+{
- u64 val64;
- int ret;
- ret = of_property_read_u64(pdev->dev.of_node, propname, &val64);
- if (ret == -EINVAL) {
*val = 0;return 0;- } else if (ret != 0) {
dev_err(&pdev->dev, "failed to parse property %s: %d\n",propname, ret);return ret;- }
- if (val64 > ULONG_MAX) {
dev_err(&pdev->dev, "invalid %s %llu\n", propname, val64);return -EOVERFLOW;- }
- *val = val64;
- return 0;
+}
Should this perhaps use the normal address parser using #address-cells and #size-cells, rather than hardcoding 64-bit?
+static int ramoops_parse_dt(struct platform_device *pdev,
struct ramoops_platform_data *pdata)+{
- struct device_node *of_node = pdev->dev.of_node;
- struct device_node *mem_region;
- struct resource res;
- u32 ecc_size;
- int ret;
- dev_dbg(&pdev->dev, "using Device Tree\n");
- mem_region = of_parse_phandle(of_node, "memory-region", 0);
- if (!mem_region) {
dev_err(&pdev->dev, "no memory-region phandle\n");return -ENODEV;- }
- ret = of_address_to_resource(mem_region, 0, &res);
- of_node_put(mem_region);
- if (ret) {
dev_err(&pdev->dev, "failed to translate memory-region to resource: %d\n",ret);return ret;- }
This is a rather odd way of doing it. Why is the ramoops block not a device under the memory region itself?
Arnd