Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green <andy.green@linaro.org>]

On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
> On 11/27/2012 09:22 PM, Andy Green wrote:
>> On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
>>> On Wed, 28 Nov 2012, Andy Green wrote:
>>>
>>>>> Greg's advice was simply not to rely on pathnames in sysfs because they
>>>>> aren't fixed in stone.  That leaves plenty of other ways to approach
>>>>> this problem.
>>>>
>>>> It's sage advice, but there is zero code provided in my patches that
>>>> "relies on pathnames in sysfs".
>>>
>>> In your 1/5 patch, _device_path_generate() concatenates device name
>>> strings, starting from a device root and separating elements with '/'
>>> characters.  Isn't that the same as a sysfs pathname?
>>
>> It's nothing to do with sysfs... yes some unrelated bits of sysfs also
>> walk the device path.  If we want to talk about how fragile the device
>> path is as an id scheme over time we need to talk about likelihood of
>> individual device names changing, not "sysfs".  Anyway -->
>>
>>>>> Basically, what you want is for something related to device A (the
>>>>> regulator or the GPIO) to happen whenever device B (the ehci-omap.0
>>>>> platform device) is bound to a driver.  The most straightforward way to
>>>>> arrange this is for A's driver to have a callback that is invoked
>>>>> whenever B is bound or unbound.  The most straightforward way to
>>>>> arrange _that_ is to allow each platform_device to have a list of
>>>>> callbacks.
>>>>
>>>> Sorry I didn't really understand this proposal yet.  You want "A", the
>>>> regulator, driver to grow a callback function that gets called when the
>>>> targeted platform_device ("B", ehci-omap.0) probe happens.  Could you
>>>> expand what the callback prototype or new members in the struct might
>>>> look like?  It's your tuple thing or we pass it an opaque pointer that
>>>> is the struct regulator * or suchlike?
>>>
>>> Well, it won't be exactly the same as the tuple thing because no
>>> strings will be involved, but it would be similar.  The callback would
>>> receive an opaque pointer (presumably to the regulator) and a device
>>> pointer (the B device).
>>
>> OK.  So I try to sketch it out iteractively to try to get in sync:
>>
>> device.h:
>>
>>      enum asset_event {
>>          AE_PROBED,
>>          AE_REMOVED
>>      };
>>
>>      struct device_asset {
>>          char *name; /* name of regulator, clock, etc */
>>          void *asset; /* regulator, clock, etc */
>>          int (*handler)(struct device *dev_owner, enum asset_event
>> asset_event, struct device_asset *asset);
>>      };
>>
>>      struct device {
>>      ...
>>          struct device_asset *assets;
>>      ...
>>      };
>>
>>
>> drivers/base/dd.c | really_probe():
>>
>> ...
>>      struct device_asset *asset;
>> ...
>>      asset = dev->assets;
>>      while (asset && asset->name) {
>>          if (asset->handler(dev, AE_PROBED, asset)) {
>>              /* clean up and bail */
>>          }
>>          asset++;
>>      }
>>
>>      /* do probe */
>> ...
>>
>>
>> drivers/base/dd.c | __device_release_driver:  (is this really the best
>> place to oppose probe()?)
>>
>> ...
>>      struct device_asset *asset;
>> ...
>>
>>      /* call device ->remove() */
>> ...
>>      asset = dev->assets;
>>      while (asset && asset->name) {
>>          asset->handler(dev, AE_REMOVED, asset);
>>          asset++;
>>      }
>> ...
>>
>>
>> board file:
>>
>>      static struct regulator myreg = {
>>          .name = "mydevice-regulator",
>>      };
>>
>>      static struct device_asset mydevice_assets[] = {
>>          {
>>              .name = "mydevice-regulator",
>>              .handler = regulator_default_asset_handler,
>>          },
>>          { }
>>      };
>>
>>      static struct platform_device mydevice = {
>>      ...
>>          .dev = {
>>              .assets = mydevice_assets,
>>          },
>>      ...
>>      };
>>
>
>  From Pandaboard's point of view, is mydevice supposed to be referring to
> ehci-omap, LAN95xx or something else?
>
> Strictly speaking, the regulator doesn't belongs neither to ehci-omap
> nor LAN95xx. It belongs to a power domain on the board. And user should
> have control to switch it OFF when required without hampering operation
> of ehci-omap, so that the other USB ports are still usable.

I'd prefer to deal with that after a try#1 with regulator, I didn't see 
any code about power domain in there right now.  There's a lot to get 
consensus on already with this series.

Notice that these assets are generic, I will provide clk and regulator 
handlers with try#1, and working examples for Panda case with both, but 
presumably power domain can fold into it as well.

Since I am on usb-next and there's nothing to be seen about power 
domains, what is the situation with that support?

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html