On 06/26/2013 01:21 PM, Kishon Vijay Abraham I wrote:
>>>>> +static int exynos_video_phy_probe(struct platform_device *pdev)
>>>>> >>>> +{
>>>>> >>>> +    struct exynos_video_phy *state;
>>>>> >>>> +    struct device *dev = &pdev->dev;
>>>>> >>>> +    struct resource *res;
>>>>> >>>> +    struct phy_provider *phy_provider;
>>>>> >>>> +    int i;
>>>>> >>>> +
>>>>> >>>> +    state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
>>>>> >>>> +    if (!state)
>>>>> >>>> +            return -ENOMEM;
>>>>> >>>> +
>>>>> >>>> +    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>> >>>> +
>>>>> >>>> +    state->regs = devm_ioremap_resource(dev, res);
>>>>> >>>> +    if (IS_ERR(state->regs))
>>>>> >>>> +            return PTR_ERR(state->regs);
>>>>> >>>> +
>>>>> >>>> +    dev_set_drvdata(dev, state);
>>>> >>>
>>>> >>> you can use platform_set_drvdata(pdev, state);
>>> >>
>>> >> I had it in the previous version, but changed for symmetry with
>>> >> dev_set_drvdata(). I guess those could be replaced with
>>> >> phy_{get, set}_drvdata as you suggested.
>
> right. currently I was setting dev_set_drvdata of phy (core) device
> in phy-core.c and the corresponding dev_get_drvdata in phy provider driver
> which is little confusing.
> So I'll add phy_set_drvdata and phy_get_drvdata in phy.h (as suggested by
> Felipe) to be used by phy provider drivers. So after creating the PHY, the
> phy provider should use phy_set_drvdata and in phy_ops, it can use
> phy_get_drvdata. (I'll remove the dev_set_drvdata in phy_create).
> 
> This also means _void *priv_ in phy_create is useless. So I'll be removing
> _priv_ from phy_create.

Yeah, sounds good. Then in the phy ops phy_get_drvdata(&phy->dev) would
be used and in a custom of_xlate dev_get_drvdata(dev) (assuming the phy
provider sets drvdata on its device beforehand).

I can't see any races from runtime PM with this approach.

Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to