Hi Linus (and Guennadi and Grant, there are questions for your below), On Tuesday 08 October 2013 13:19:04 Linus Walleij wrote: > On Mon, Sep 30, 2013 at 1:10 PM, Laurent Pinchart wrote: > > Hi Linus, > > > > [Updated the devicetree mailing list e-mail address] > > > > On Monday 30 September 2013 01:20:46 Linus Walleij wrote: > >> On Sun, Sep 29, 2013 at 8:49 AM, Laurent Pinchart wrote: > >> > On Friday 27 September 2013 16:08:31 Linus Walleij wrote: > >> >> Can't you just locate the node using of_find_node_by_path() > >> >> or whatever and then use this: > >> >> int of_update_property(struct device_node *np, struct property > >> >> *newprop)? > >> > > >> > Where can I do that ? I need the PFC/GPIO devices to have been probed, > >> > so board init isn't an option, but I also need the device to be enabled > >> > not to have been probed yet. > >> > > >> > One option would be to use a bus notifier to find out when the PFC/GPIO > >> > devices are available, and extend of_update_property() with a > >> > notification mechanism (either generic, or specific to the enabled > >> > propery) to detect when a device gets enabled and probe it. > >> > >> Argh that sounds awfully complicated... > >> > >> I would consider doing this right inside the PCF/GPIO driver right at the > >> end of its probe function. As it is related to pins anyway... or is that > >> too ugly? > > > > As a reminder, we need to decide whether to register an SDHI (SD > > controller) device or a WiFi module device, and thus configure pinmuxing > > appropriately, based on the state of a GPIO connected to a > > user-accessible switch. This behaviour is board-specific, not > > SoC-specific. That's why I believe the code should be in board code. > > Hm, I might have misunderstood this earlier, so if the board code is > going to register *either* SDHI *or* WIFI, both as some kind of > struct device then as you say: > > > The board has two connectors (MMC/SD 1 > > and wifi module) that are not usable concurrently. The user can select > > which connector to use through a hardware switch that existing board code > > reads at init time (...) > > So depending on what you read there you're going to register a struct device > named mmc0 or wifi0 or something, then you just register the pin control > tables for both cases and the apropriate default state will be selected by > the device core right before the device driver gets probed. (grep for > pinctrl_bind_pins). It is perfectly fine to have unused pin states in the > table. > > Then the problem is unrelated to pin control and more about how to register > these devices, nothing to do with pin control. Correct. > Such as if they should both be marked as "disabled" in the DT and activated > by the kernel, or registered by adding a platform device or something... I believe a way to mark a disabled device as enabled from board code would be interesting. The function could be called from a platform bus notifier that reacts on the GPIO device being probed. It's a bit of a corner case, but it doesn't sound too hackish to me. Grant, would you be fine with such a mechanism ? The devices would be marked with status = "disabled" in DT and a new function would be added to enable them. That function would modify the DT status to "okay" and trigger device registration. > But I guess I got it wrong? I believe you got it right. At least your understanding matches mine :-) Guennadi, could you please confirm ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
