On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:

+/**
+ * struct sc_phy - The basic smart card phy structure
+ *
+ * @dev: phy device
+ * @pdata: pointer to phy's private data structure
+ * @set_config: called to set phy's configuration
+ * @get_config: called to get phy's configuration
+ * @activate_card: perform smart card activation
+ * @deactivate_card: perform smart card de-activation
+ * @warm_reset: execute smart card warm reset sequence
+ * @register_card_activity_cb: register call back to phy device.
+ * This call back will be called on card insert or remove event
+ *
+ * smart card controller uses this interface to communicate with
+ * smart card via phy.Some smart card phy has multiple slots for
+ * cards. This inerface also enables controller to communicate with
+ * one or more smart card connected over phy.
+ */
+struct sc_phy {
+	/* phy's device pointer */
+	struct device *dev;

So this is the "parent", right?  Why not embed a struct device into this
structure as well, further streaching out the device tree.

+
+	/* phy's private data */
+	void *pdata;

If you do the above, then this pointer is not needed.

+
+	/* notify data, passed by interface user as a part of
+	 * register_notify API. Data should be passed back when
+	 * notification raised to the interface user
+	 */
+	void *notify_data;

What makes this different from the pdata?

+
+	int	(*set_config)(struct sc_phy *phy, u8 slot,
+			enum sc_phy_config attr, int value);
+	int	(*get_config)(struct sc_phy *phy, u8 slot, enum
+			sc_phy_config attr);
+	int	(*activate_card)(struct sc_phy *phy, u8 slot);
+	int	(*deactivate_card)(struct sc_phy *phy, u8 slot);
+	int	(*get_syncatr)(struct sc_phy *phy, u8 slot, u8 len, char *atr);
+	int	(*warm_reset)(struct sc_phy *phy, u8 slot);
+	int	(*register_notify)(struct sc_phy *phy,
+			 struct	notifier_block *nb, void *notify_data);
+	int	(*unregister_notify)(struct sc_phy *phy,
+			struct	notifier_block *nb);
+};
+
+#endif /* __SC_PHY_H__ */
-- 
1.7.9.5