Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Lee Jones <hidden>
Date: 2017-01-06 09:51:25
Also in:
linux-iio, linux-leds, lkml
On Thu, 05 Jan 2017, Bjorn Andersson wrote:
On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:quoted
On Wed, 04 Jan 2017, Bjorn Andersson wrote:quoted
On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:quoted
On Mon, 26 Dec 2016, Bjorn Andersson wrote:quoted
From: Bjorn Andersson <redacted> Implement support for initialization of the lm3533 driver core and probing child devices from Device Tree.[..]quoted
quoted
@@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533) lm3533_device_bl_init(lm3533); lm3533_device_led_init(lm3533); + if (lm3533->dev->of_node) { + of_platform_populate(lm3533->dev->of_node, NULL, NULL, + lm3533->dev); + }I think it's save to call of_platform_populate(), even if !of_node. It will just fail and return an error code, which you are ignoring anyway.I thought so too, but that's apparently how you trigger probing children of the root node. So we're stuck with a conditional.Ah, so this is to protect against the case where DT is present, but a node for this device is not (or is disabled), so is left unprobed. Then the bind is initiated via I2C? Or something else?In the event that a new lm3533 is spawned from sysfs we would not have platform_data when entering lm3533_device_init() and just bail early. Therefor, this issue would be limited to the odd case of lm3533 being initiated from code (e.g. a board file) on a DT enabled system. In which case it will create and probe new devices from the root of the DT.
Eewww, do we really want to support that? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog