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: <CAMdRc4F2EaDxrBAMUQ3NGvBt4sMnYX3FQXZttFzcPZJdKkOMLw@mail.gmail.com>
Date:	Fri, 27 Feb 2015 16:08:11 +0100
From:	Robert Abel <rabel@...-ec.uni-bielefeld.de>
To:	Roger Quadros <rogerq@...com>
Cc:	balbi@...com, linux-omap@...r.kernel.org,
	linux-usb@...r.kernel.org,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>, linux@....linux.org.uk
Subject: Re: [PATCH 2/8] ARM OMAP2+ GPMC: add bus children

Hi Roger,

On Fri, Feb 27, 2015 at 11:24 AM, Roger Quadros <rogerq@...com> wrote:
>> +     /* is child a common bus? */
>> +     if (of_match_node(of_default_bus_match_table, child))
>> +             /* create children and other common bus children */
>> +             if (of_platform_populate(child, of_default_bus_match_table, NULL, &pdev->dev))
>> +                     goto err_child_fail;
>
> this would print "failed to create gpmc child" but we have already created
> the gpmc child in the first of_platform_device_create() call.
> A more appropriate message would be "failed to populate all children of child->name"
>
> Also do you want to return failure?
> it will result in of_node_put() of the child and another print message
> about "probing gpmc child %s failed" in gpmc_probe_dt().
>
> IMO if the GPMC node's child was created fine then we shouldn't return error.

As of_platform_populate _always_ return 0 no matter what, the only way
to reach that message is if probing the child failed.
As I cannot see into the future when of_platform_populate might
actually be changed to return meaningful codes, we shouldn't try to
foresee what the actual problem might be today either. This is a
battle for another day.

Regards,

Robert
--
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