linux-kernel - Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new 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]

Date:   Mon, 21 Nov 2016 17:43:54 -0800
From:   Frank Rowand <frowand.list@...il.com>
To:     Sekhar Nori <nsekhar@...com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Russell King <linux@...linux.org.uk>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        linux-drm <dri-devel@...ts.freedesktop.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        Jyri Sarha <jsarha@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        David Airlie <airlied@...ux.ie>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver

Hi Sekhar,

(And adding Sudeep since he becomes involved in this further
down thread and at that point says he will re-work this
proposed work around in a manner that is incorrect in a
manner that is similar to this proposed work around.)

On 11/21/16 08:33, Sekhar Nori wrote:
> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> +{
>> +	const struct da8xx_ddrctl_config_knob *knob;
>> +	const struct da8xx_ddrctl_setting *setting;
>> +	struct device_node *node;
>> +	struct resource *res;
>> +	void __iomem *ddrctl;
>> +	struct device *dev;
>> +	u32 reg;
>> +
>> +	dev = &pdev->dev;
>> +	node = dev->of_node;
>> +
>> +	setting = da8xx_ddrctl_get_board_settings();
>> +	if (!setting) {
>> +		dev_err(dev, "no settings for board '%s'\n",
>> +			of_flat_dt_get_machine_name());
>> +		return -EINVAL;
>> +	}
> 
> This causes a section mismatch because of_flat_dt_get_machine_name() 
> has an __init annotation. I did not notice that before, sorry.
> 
> It can be fixed with a patch like below:
> 
> ---8<---
> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
> index a20e7bbbcbe0..9ca5aab3ac54 100644
> --- a/drivers/memory/da8xx-ddrctl.c
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
>  	return NULL;
>  }
>  
> +static const char* da8xx_ddrctl_get_machine_name(void)
> +{
> +	const char *str;
> +	int ret;
> +
> +	ret = of_property_read_string(of_root, "model", &str);
> +	if (ret)
> +		ret = of_property_read_string(of_root, "compatible", &str);
> +
> +	return str;
> +}
> +
>  static int da8xx_ddrctl_probe(struct platform_device *pdev)
>  {
>  	const struct da8xx_ddrctl_config_knob *knob;
> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
>  	setting = da8xx_ddrctl_get_board_settings();
>  	if (!setting) {
>  		dev_err(dev, "no settings for board '%s'\n",
> -			of_flat_dt_get_machine_name());

da8xx_ddrctl_get_board_settings() tries to match based on the "compatible"
property in the root node.  The "model" property in the root node has
nothing to do with the failure to match. So creating and then using
da8xx_ddrctl_get_machine_name() to potentially report model is not useful.

It should be sufficient to simply report that no compatible matched.


> +			da8xx_ddrctl_get_machine_name());
>  		return -EINVAL;
>  	}
> ---8<--- 
> 
> A similar fix is required for the other driver in this series (patch 
> 2/5). I need some advise on whether I should introduce a common 
> function to get the machine name post kernel boot-up (I cannot see an 
> existing one). If yes, any advise on which file it should go into?
> 
> Thanks,
> Sekhar
> 
>