linux-kernel - Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller

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: <e55af89e-71ac-136e-09c6-98d20e133b78@exceet.de>
Date:   Wed, 30 May 2018 17:13:44 +0200
From:   Frieder Schrempf <frieder.schrempf@...eet.de>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
Cc:     linux-mtd@...ts.infradead.org, linux-spi@...r.kernel.org,
        dwmw2@...radead.org, computersforpeace@...il.com,
        marek.vasut@...il.com, richard@....at, miquel.raynal@...tlin.com,
        broonie@...nel.org, david.wolfe@....com, fabio.estevam@....com,
        prabhakar.kushwaha@....com, yogeshnarayan.gaur@....com,
        han.xu@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI
 controller

Hi Boris,

On 30.05.2018 16:58, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Wed, 30 May 2018 15:14:32 +0200
> Frieder Schrempf <frieder.schrempf@...eet.de> wrote:
> 
>> +
>> +static const char *fsl_qspi_get_name(struct spi_mem *mem)
>> +{
>> +	struct fsl_qspi *q = spi_controller_get_devdata(mem->spi->master);
>> +	struct device *dev = &mem->spi->dev;
>> +	const char *name;
>> +
>> +	/*
>> +	 * In order to keep mtdparts compatible with the old MTD driver at
>> +	 * mtd/spi-nor/fsl-quadspi.c, we set a custom name derived from the
>> +	 * platform_device of the controller.
>> +	 */
>> +	if (of_get_available_child_count(q->dev->of_node) == 1)
>> +		name = dev_name(q->dev);
>> +	else
>> +		name = devm_kasprintf(dev, GFP_KERNEL,
>> +				      "%s-%d", dev_name(q->dev),
>> +				      mem->spi->chip_select);
>> +
>> +	if (!name) {
>> +		dev_err(dev, "failed to get memory for custom flash name\n");
>> +		return dev_name(q->dev);
> 
> Hm, not sure that's what we want. We should probably fail when the
> allocation fails.

Right, we should definitely fail when the allocation fails.

> 
> How about letting ->get_name() return an error pointer or NULL in case
> of error. With the other I made suggestion in my review of patch 1
> (calling ->get_name() at probe time) you could refuse to probe the
> device when ->get_name() fails.

Ok, I will change that.

Thanks,

Frieder

> 
>> +	}
>> +
>> +	return name;
>> +}
>> +
> 
> Regards,
> 
> Boris
>