On 03/29/12 16:55, Paul Gortmaker wrote:
> On 12-03-29 10:28 AM, Igor Grinberg wrote:
>> On 03/28/12 18:59, Paul Gortmaker wrote:
>>> On 12-03-28 12:13 PM, Mark Brown wrote:
>>>> On Wed, Mar 28, 2012 at 11:59:41AM -0400, Paul Gortmaker wrote:
>>>>> On 12-03-28 11:27 AM, Mark Brown wrote:
>>>>
>>>>> static struct platform_device em_x270_gps_userspace_consumer = {
>>>>> .name = "reg-userspace-consumer",
>>>>> .id = 0,
>>>>
>>>>> static struct platform_device em_x270_gprs_userspace_consumer = {
>>>>> .name = "reg-userspace-consumer",
>>>>> .id = 1,
>>>>
>>>>> Note that the existing names currently don't incorporate the .id
>>>>> field as a suffix, and so never were unique.
>>>>
>>>> No, this is just a basic part of how platform devices work - the device
>>>> name is always the same and if you've got more than one of them they get
>>>> different .ids. dev_name() returns name.id, or just name if id is set
>>>> to -1 indicating that there's onyl one device of a given type.
>>>
>>> OK, so Igor - can you simply retest the v2 patch, but make the
>>> two trivial changes:
>>>
>>> -REGULATOR_CONSUMER(ldo3, "reg-userspace-consumer", "vcc gps");
>>> +REGULATOR_CONSUMER(ldo3, "reg-userspace-consumer.0", "vcc gps");
>>>
>>> -REGULATOR_CONSUMER(ldo19, "reg-userspace-consumer", "vcc gprs");
>>> +REGULATOR_CONSUMER(ldo19, "reg-userspace-consumer.1", "vcc gprs");
>>
>> Well, I thought of this solution, but I don't like it, as it makes
>> the whole thing very fragile and sensitive to the reg-userspace-consumer
>> platform device registration order and count, isn't it?
>
> Why would it be order dependent? You can see in the above structs
> that they explicitly call out an ID value -- it is _not_ chosen at
> the time of registration. So it will always be:
>
> reg-userspace-consumer.0 --> gps consumer
> reg-userspace-consumer.1 --> gprs consumer
>
> At least that is my (limited) understanding, based on what
> Mark was saying.
The problem is, that someone has to stop sending emails in a hurry...
Spitting all the mix in the head when in rush...
and that would be me...
Sorry, for the mess, I'll try to fix myself up...
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
