linux-kernel - Re: [PATCH v3 10/13] memory: tegra: Add EMC (external memory controller) 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] [day] [month] [year] [list]

Date:	Fri, 7 Nov 2014 17:16:23 +0100
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	Mikko Perttunen <mikko.perttunen@...si.fi>
Cc:	Alexandre Courbot <acourbot@...dia.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Mikko Perttunen <mperttunen@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Ivan Khoronzhuk <ivan.khoronzhuk@...com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Scott Wood <scottwood@...escale.com>,
	Bharat Bhushan <bharat.bhushan@...escale.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Prabhakar Kushwaha <prabhakar@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 10/13] memory: tegra: Add EMC (external memory
 controller) driver

On 6 November 2014 12:35, Mikko Perttunen <mikko.perttunen@...si.fi> wrote:
> On 11/06/2014 09:56 AM, Alexandre Courbot wrote:
>>
>> On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
>>> +static int tegra_emc_probe(struct platform_device *pdev)
>>> +{
>>> +    struct tegra_emc *tegra;
>>> +    struct device_node *node;
>>> +    struct platform_device *mc_pdev;
>>> +    struct resource *res;
>>> +    u32 ram_code, node_ram_code;
>>> +    int err;
>>> +
>>> +    tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
>>> +    if (!tegra)
>>> +        return -ENOMEM;
>>> +
>>> +    tegra->pdev = pdev;
>>> +
>>> +    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +    tegra->emc_regs = devm_ioremap_resource(&pdev->dev, res);
>>> +    if (IS_ERR(tegra->emc_regs)) {
>>> +        dev_err(&pdev->dev, "failed to map EMC regs\n");
>>> +        return PTR_ERR(tegra->emc_regs);
>>> +    }
>>> +
>>> +    node = of_parse_phandle(pdev->dev.of_node,
>>> +                "nvidia,memory-controller", 0);
>>> +    if (!node) {
>>> +        dev_err(&pdev->dev, "could not get memory controller\n");
>>> +        return -ENOENT;
>>> +    }
>>> +
>>> +    mc_pdev = of_find_device_by_node(node);
>>> +    if (!mc_pdev)
>>> +        return -ENOENT;
>>
>>
>> Isn't there a risk that we will return -ENOENT depending on the probe
>> order? I.e. if this device is probed before the MC device?
>
>
> Yes.. I remember having some trouble with this code. IIRC, I couldn't figure
> out a way to sanely detect if the MC driver had been probed or not. Clearly
> this is not good, though.

Yeah, I found this issue during testing and resorted to
subsys_initcall(). Any better ideas?

Thanks,

Tomeu
--
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/