lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1436806229.11945.5.camel@pengutronix.de>
Date:	Mon, 13 Jul 2015 18:50:29 +0200
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	stefan.wahren@...e.com, devicetree@...r.kernel.org, arnd@...db.de,
	linux-api@...r.kernel.org, s.hauer@...gutronix.de,
	sboyd@...eaurora.org, linux-kernel@...r.kernel.org,
	Rob Herring <robh+dt@...nel.org>,
	pantelis.antoniou@...sulko.com, Mark Brown <broonie@...nel.org>,
	Kumar Gala <galak@...eaurora.org>, mporter@...sulko.com,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	linux-arm-msm@...r.kernel.org, wxt@...k-chips.com
Subject: Re: [PATCH v7 1/9] nvmem: Add a simple NVMEM framework for nvmem
 providers

Hi Srinivas,

Am Freitag, den 10.07.2015, 10:44 +0100 schrieb Srinivas Kandagatla:
> This patch adds just providers part of the framework just to enable easy
> review.
[...]
> +/**
> + * nvmem_register() - Register a nvmem device for given nvmem_config.
> + * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
> + *
> + * @config: nvmem device configuration with which nvmem device is created.
> + *
> + * The return value will be an ERR_PTR() on error or a valid pointer
> + * to nvmem_device.
> + */
> +
> +struct nvmem_device *nvmem_register(struct nvmem_config *config)
> +{
[...]
> +	nvmem->read_only = nvmem->dev.of_node ?
> +				of_property_read_bool(nvmem->dev.of_node,
> +				"read-only") :
> +				config->read_only;

I think read_only should be set if any of the device node property or
nvmem_config->read_only request it. That way, even if the nvmem is
theoretically writeable (no read-only property in DT), the driver still
can make it read-only if writing isn't implemented:

+	nvmem->read_only = nvmem->dev.of_node ?
+				of_property_read_bool(nvmem->dev.of_node,
+				"read-only") : 0;
+	nvmem->read_only |= config->read_only;

[...]
> new file mode 100644
> index 0000000..f589d3b
> --- /dev/null
> +++ b/include/linux/nvmem-provider.h
[...]
> +struct nvmem_config {
> +	struct device		*dev;
> +	const char		*name;
> +	int			id;
> +	struct module		*owner;
> +	struct nvmem_cell_info	*cells;

Should that be const?

> +	int			ncells;
> +	bool			read_only;
> +};
> +
> +#if IS_ENABLED(CONFIG_NVMEM)
> +
> +struct nvmem_device *nvmem_register(struct nvmem_config *cfg);

Then that could be made const, too.

best regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ