linux-kernel - Re: [PATCH 2/3] nvmem: mediatek: Add Mediatek EFUSE driver

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: <562E02F2.50709@linaro.org>
Date:	Mon, 26 Oct 2015 10:39:46 +0000
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
CC:	andrew-ct.chen@...iatek.com,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
	srv_heupstream@...iatek.com
Subject: Re: [PATCH 2/3] nvmem: mediatek: Add Mediatek EFUSE driver



On 26/10/15 10:28, Sascha Hauer wrote:
> On Mon, Oct 26, 2015 at 09:56:24AM +0000, Srinivas Kandagatla wrote:
>>> +	.val_bits = 32,
>>> +	.reg_stride = 4,
>>> +};
>>> +
>>> +static int mtk_efuse_probe(struct platform_device *pdev)
>>> +{
>>> +	struct device *dev = &pdev->dev;
>>> +	struct resource *res;
>>> +	struct nvmem_device *nvmem;
>>> +	struct nvmem_config *econfig;
>>> +	struct regmap *regmap;
>>> +	void __iomem *base;
>>> +
>>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +	base = devm_ioremap_resource(dev, res);
>>> +	if (IS_ERR(base))
>>> +		return PTR_ERR(base);
>>> +
>>> +	econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
>>> +	if (!econfig)
>>> +		return -ENOMEM;
>> Why not use static econfig variable?
>
> Because drivers should not assume there is only one instance of them in
> the system. The qfprom driver does this and it's only a matter of
Good point, Yes, you are right. If MTK has possibility of having more 
than one efuse we can leave the code as it is.
> putting a second qcom,qfprom node into the device tree to break the
> driver.
It would indeed.
--srini
>
> Sascha
>
--
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/