<resend with the CC really added back>
Hi,
On 08/08/2017 04:42 PM, Mark Brown wrote:
On Tue, Aug 08, 2017 at 02:56:46PM +0100, Hans de Goede wrote:
Hi,
Please don't take things off-list unless there is a really strong reason
to do so. Sending things to the list ensures that everyone gets a
chance to read and comment on things.
Sorry, that was unintentional I probably accidentally hit reply instead
of reply-to-all.
I've re-added the lists to the Cc.
On 08/08/2017 10:39 AM, Mark Brown wrote:
On Mon, Aug 07, 2017 at 09:20:05PM +0200, Hans de Goede wrote:
Why not? This is just really standard usage of platform data.
Right, but in general in most cases we are trying to get rid of
platform data (where possible). So introducing new platform_data
is not going to be popular, but I agree that it likely is the
best solution here.
No, we aren't. The majority of architectures are still platform data
only and x86 as you're finding uses it extensively along with ACPI.
Ok.
Alternatively the entry could additionally contain a provider_supply_name
so that we can make arbitrary consumer-dev-name + consumer-supply-name
provider-dev-name + provider-supply-name matches. That would probably
be more flexible then requiring the supply name to match.
I'm sorry but I can't follow what you mean here. What do you mean by
"provider_supply_name"?
The current "const char *supply" in regulator_map is the supply name
passed to regulator_get, so the rdev_get_name requested by the consumer
(assuming no mapping is in place)
The name on the parent is *NOT* something anything else should
reference, it's just some internal documentation intended exclusively
for human consmption and can be overridden by the platforms. It should
never be referenced by anything outside the device.
One regulator parent-device can register multiple regulator names, iow
multiple supplies, basically what I want to do is have the map
(when not using the regulator pointer) match the following 2 pairs:
dev_name + supply
regulator_parent_dev_name + rdev_get_name
Have your platform register identifiers that are useful within your
platform, don't rely on the drivers.
Ok, I need to think a bit about this. I think I've enough info to
come up with a new patch-set not introducing the fcs,vbus-regulator-name
device-property ugliness. But this is a side project and I'm rather busy with $dayjob
atm, so it may take a while for me to come up with a new patch.
Regards,
Hans
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
