Hi, On Friday 20 June 2014 02:38 AM, me...@codeaurora.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
