| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <986b53d6-ef65-bc1f-38a8-f981e23a6f02@rock-chips.com>
Date: Tue, 21 Jun 2016 15:52:45 +0800
From: Frank Wang <frank.wang@...k-chips.com>
To: Heiko Stübner <heiko@...ech.de>
Cc: Guenter Roeck <linux@...ck-us.net>,
Guenter Roeck <groeck@...gle.com>,
Guenter Roeck <groeck@...omium.org>,
Douglas Anderson <dianders@...omium.org>, jwerner@...omium.org,
Kishon Vijay Abraham I <kishon@...com>, robh+dt@...nel.org,
pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, Kumar Gala <galak@...eaurora.org>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-usb@...r.kernel.org, linux-rockchip@...ts.infradead.org,
Ziyuan Xu <xzy.xu@...k-chips.com>,
Kever Yang <kever.yang@...k-chips.com>,
Tao Huang <huangtao@...k-chips.com>, william.wu@...k-chips.com,
frank.wang@...k-chips.com
Subject: Re: [PATCH v6 2/2] phy: rockchip-inno-usb2: add a new driver for
Rockchip usb2phy
Hi Heiko,
On 2016/6/20 12:56, Guenter Roeck wrote:
> Hi Frank,
>
> On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang <frank.wang@...k-chips.com> wrote:
>> Hi Heiko & Guenter,
>>
>>
>> On 2016/6/20 11:00, Guenter Roeck wrote:
>>> On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang <frank.wang@...k-chips.com>
>>> wrote:
>>>> Hi Guenter,
>>>>
>>>>
>>>> On 2016/6/17 21:20, Guenter Roeck wrote:
>>>>> Hi Frank,
>>>>>
>>>>> On 06/16/2016 11:43 PM, Frank Wang wrote:
>>>>>> Hi Guenter,
>>>>>>
>>>>>> On 2016/6/17 12:59, Guenter Roeck wrote:
>>>>>>> On 06/16/2016 07:09 PM, Frank Wang wrote:
>>>>>>>> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
>>>>>>>> than rk3288 and before, and most of phy-related registers are also
>>>>>>>> different from the past, so a new phy driver is required necessarily.
>>>>>>>>
>>>>>>>> Signed-off-by: Frank Wang <frank.wang@...k-chips.com>
>>>>>>>> Suggested-by: Guenter Roeck <linux@...ck-us.net>
>>>>>>>> Suggested-by: Doug Anderson <dianders@...omium.org>
>>>>>>>> Reviewed-by: Heiko Stuebner <heiko@...ech.de>
>>>>>>>> Tested-by: Heiko Stuebner <heiko@...ech.de>
>>>>>>>> ---
>>>>>>>
>>>>>>> [ ... ]
>>>>>>>
>>>>>>>> +
>>>>>>>> +static int rockchip_usb2phy_resume(struct phy *phy)
>>>>>>>> +{
>>>>>>>> + struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
>>>>>>>> + struct rockchip_usb2phy *rphy =
>>>>>>>> dev_get_drvdata(phy->dev.parent);
>>>>>>>> + int ret;
>>>>>>>> +
>>>>>>>> + dev_dbg(&rport->phy->dev, "port resume\n");
>>>>>>>> +
>>>>>>>> + ret = clk_prepare_enable(rphy->clk480m);
>>>>>>>> + if (ret)
>>>>>>>> + return ret;
>>>>>>>> +
>>>>>>> If suspend can be called multiple times, resume can be called
>>>>>>> multiple times as well. Doesn't this cause a clock imbalance
>>>>>>> if you call clk_prepare_enable() multiple times on resume,
>>>>>>> but clk_disable_unprepare() only once on suspend ?
>>>>>>>
>>>>>> Well, what you said is reasonable, How does something like below?
>>>>>>
>>>>>> @@ -307,6 +307,9 @@ static int rockchip_usb2phy_resume(struct phy *phy)
>>>>>>
>>>>>> dev_dbg(&rport->phy->dev, "port resume\n");
>>>>>>
>>>>>> + if (!rport->suspended)
>>>>>> + return 0;
>>>>>> +
>>>>>> ret = clk_prepare_enable(rphy->clk480m);
>>>>>> if (ret)
>>>>>> return ret;
>>>>>> @@ -327,12 +330,16 @@ static int rockchip_usb2phy_suspend(struct phy
>>>>>> *phy)
>>>>>>
>>>>>> dev_dbg(&rport->phy->dev, "port suspend\n");
>>>>>>
>>>>>> + if (rport->suspended)
>>>>>> + return 0;
>>>>>> +
>>>>>> ret = property_enable(rphy, &rport->port_cfg->phy_sus, true);
>>>>>> if (ret)
>>>>>> return ret;
>>>>>>
>>>>>> rport->suspended = true;
>>>>>> clk_disable_unprepare(rphy->clk480m);
>>>>>> +
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> @@ -485,6 +492,7 @@ static int rockchip_usb2phy_host_port_init(struct
>>>>>> rockchip_usb2phy *rphy,
>>>>>>
>>>>>> rport->port_id = USB2PHY_PORT_HOST;
>>>>>> rport->port_cfg =
>>>>>> &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_HOST];
>>>>>> + rport->suspended = true;
>>>>>>
>>>>> Why does it start in suspended mode ? That seems odd.
>>>>>
>>>> This is an initialization. Using above design which make 'suspended' as a
>>>> condition both in *_usb2phy_resume and *_usb2phy_suspend, I believe if it
>>>> is
>>>> not initialized as suspended mode, the first resume process will be
>>>> skipped.
>>> I had to re-read the entire patch.
>>>
>>> Turns out my problem was one of terminology. Using "suspend" and
>>> "resume" to me suggested the common use of suspend and resume
>>> functions. That is not the case here. After mentally replacing
>>> "suspend" with "power_off" and "resume" with "power_on", you are
>>> right, no problem exists. Sorry for the noise.
>>>
>>> Maybe it would be useful to replace "resume" with "power_on" and
>>> "suspend" with "power_off" in the function and variable names to
>>> reduce confusion and misunderstandings.
>>>
>>> Thanks,
>>> Guenter
>>
>> Well, it does have a bits confusion, however, the phy-port always just goes
>> to suspend and resume mode (Not power off and power on) in a fact. So must
>> it be renamed?
>>
> Other phy drivers name the functions _power_off and _power_on and
> avoid the confusion. The callbacks are named .power_off and .power_on,
> which gives a clear indication of its intended purpose. Other drivers
> implementing suspend/resume (such as the omap usb phy driver) tie
> those functions not into the power_off/power_on callbacks, but into
> the driver's suspend/resume callbacks. At least the omap driver has
> separate power management functions.
>
> Do the functions _have_ to be renamed ? Surely not. But, if the
> functions are really suspend/resume functions and not
> power_off/power_on functions, maybe they should tie to the
> suspend/resume functions and not register themselves as
> power_off/power_on functions ?
>
> Thanks,
> Guenter
As Guenter mentioned above, I doped out two solutions, one is that keep
current process but renaming *_resume/*_suspend to
*_power_on/*_power_off; another is that do not assign power_on/power_off
functions for phy_ops at phy creating time, then, shorten
_SCHEDULE_DELAY_ delay time less that 10 Seconds, and the phy-port
suspend/resume mechanism depend on _sm_work_ completely.
So which is the better way from your view? or would you like to give
other unique perceptions please?
BR.
Frank
>>
>>>> Theoretically, the phy-port in suspended mode make sense when it is at
>>>> start
>>>> time, then the upper layer controller will invoke phy_power_on (See
>>>> phy-core.c), and it further call back *_usb2phy_resume to make phy-port
>>>> work
>>>> properly.
>>>>
>>>> So could you tell me what make you feeling odd or would you like to give
>>>> another appropriate way please? :-)
>>>>
>>>> BR.
>>>> Frank
>>>>
>>>>
>>>>>> mutex_init(&rport->mutex);
>>>>>> INIT_DELAYED_WORK(&rport->sm_work, rockchip_usb2phy_sm_work);
>>>>>>
Powered by blists - more mailing lists