linux-kernel - Re: Specific PHYs operation for phy-core

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <53B4277B.9070707@ti.com>
Date:	Wed, 2 Jul 2014 21:08:35 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	<merez@...eaurora.org>
CC:	<noag@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Specific PHYs operation for phy-core

Hi,

On Friday 20 June 2014 02:38 AM, merez@...eaurora.org wrote:
> Hi,
> 
> We would like to use the phy-core framework for the UFS PHY implementation
> and we would appreciate your help with the following questions:
> 1. Our initialization sequence includes going back and forth operations
> between the core and the PHY. Due to that, the "init" function alone
> cannot hold the complete initialization sequence.
> The options we could think of are either add pre_init and post_init
> functions or add PHY specific functions.

pre-init and post-init seems to be too generic to be used. Would like 'ops'
that is more clearly defined (like 'reset' ops or 'calibrate' ops apart from
other existing ones where you know what should be done in the callback). If you
can explain what exact operations you are talking about we can see if it can be
fit in any existing or new generic ops.
> How do you recommend to resolve such a case?
> Have you thought about a way to expose PHY specific functions?

Exposing PHY specific functions are not recommended (since it is like ioctl)
and can be abused easily.
> 
> 2. Our core needs to check if the PCS (Physical Coding Sublayer) is ready
> as part of its flow. As this is a term that is present in almost all the
> serial PHYs, can we add is_pcs_ready() API to the generic PHY ops?
> If not, how do you recommend to resolve this?

yeah, was thinking about adding states to PHY since it looks to have other uses
apart from your use case. Something like PHY_STATE_DEFAULT, PHY_STATE_INIT,
PHY_STATE_POWERED, PHY_STATE_READY etc.. Then we can have phy_get_state to see
if the PHY is ready or not.
> 
> I would appreciate your prompt response as we would like to close the
> design by Monday.

ah.. sorry.

Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/