From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932236AbbFEC4e (ORCPT ); Thu, 4 Jun 2015 22:56:34 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:49471 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753518AbbFEC4c (ORCPT ); Thu, 4 Jun 2015 22:56:32 -0400 Message-ID: <55710FDE.90609@wwwdotorg.org> Date: Thu, 04 Jun 2015 20:56:30 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Anholt CC: linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Lee Jones , devicetree@vger.kernel.org, Mike Turquette , Stephen Boyd Subject: Re: [PATCH 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver. References: <1431978219-14226-1-git-send-email-eric@anholt.net> <1431978219-14226-3-git-send-email-eric@anholt.net> <55679085.6040402@wwwdotorg.org> <87h9qvcd1i.fsf@eliezer.anholt.net> In-Reply-To: <87h9qvcd1i.fsf@eliezer.anholt.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/29/2015 03:02 PM, Eric Anholt wrote: > Stephen Warren writes: > >> On 05/18/2015 01:43 PM, Eric Anholt wrote: >>> +static struct clk *rpi_firmware_delayed_get_clk(struct >>> of_phandle_args *clkspec, + void *_data) >> >>> + rpi_clk = &rpi_clocks[clkspec->args[0]]; + + firmware_node = >>> of_parse_phandle(of_node, "firmware", 0); + if (!firmware_node) >>> { + dev_err(dev, "%s: Missing firmware node\n", >>> rpi_clk->name); + return ERR_PTR(-ENODEV); + } + + /* Try a >>> no-op transaction to see if the driver is loaded yet. */ + ret >>> = rpi_firmware_property_list(firmware_node, NULL, 0); + if >>> (ret) + return ERR_PTR(ret); >> >> I would move all that into this driver's probe(). > > We can't move all this into the driver's probe, because this is > where we're returning -EPROBE_DEFER. We could potentially do just > the phandle parse up front and allocate some memory to pass it and > our own device node to this function through the _data arg, but I > don't see much point. Well, once the clock core correctly supports deferred probe, that can be moved. Aside from that, I think all your other replies to my replies in this thread/series make sense.