From: Satish Patel <satish.patel-l0cyMroinI0@public.gmane.org>
To: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller
Date: Thu, 29 May 2014 14:26:55 +0530 [thread overview]
Message-ID: <5386F657.9040805@ti.com> (raw)
In-Reply-To: <20140528184408.GC30031-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On 5/29/2014 12:14 AM, Greg KH wrote:
> 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.
>
Do you mean to use "dev->p" for pdata ?
I have kept it outside, to give easeness/pragmatic focal for new phy
driver development. Driver can make this pointer null and use above pointer.
>> +
>> + /* 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?
pdata is phy's private data, while notify_data is something phy will
send to smart card controller on some event, like card
remove/insert/timeout etc..
>
>
>> +
>> + 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: satish.patel@ti.com (Satish Patel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller
Date: Thu, 29 May 2014 14:26:55 +0530 [thread overview]
Message-ID: <5386F657.9040805@ti.com> (raw)
In-Reply-To: <20140528184408.GC30031@kroah.com>
On 5/29/2014 12:14 AM, Greg KH wrote:
> 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.
>
Do you mean to use "dev->p" for pdata ?
I have kept it outside, to give easeness/pragmatic focal for new phy
driver development. Driver can make this pointer null and use above pointer.
>> +
>> + /* 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?
pdata is phy's private data, while notify_data is something phy will
send to smart card controller on some event, like card
remove/insert/timeout etc..
>
>
>> +
>> + 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
WARNING: multiple messages have this Message-ID (diff)
From: Satish Patel <satish.patel@ti.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-omap@vger.kernel.org>, <devicetree@vger.kernel.org>,
<rob@landley.net>, <tony@atomide.com>, <grant.likely@linaro.org>,
<robh+dt@kernel.org>
Subject: Re: [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller
Date: Thu, 29 May 2014 14:26:55 +0530 [thread overview]
Message-ID: <5386F657.9040805@ti.com> (raw)
In-Reply-To: <20140528184408.GC30031@kroah.com>
On 5/29/2014 12:14 AM, Greg KH wrote:
> 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.
>
Do you mean to use "dev->p" for pdata ?
I have kept it outside, to give easeness/pragmatic focal for new phy
driver development. Driver can make this pointer null and use above pointer.
>> +
>> + /* 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?
pdata is phy's private data, while notify_data is something phy will
send to smart card controller on some event, like card
remove/insert/timeout etc..
>
>
>> +
>> + 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
next prev parent reply other threads:[~2014-05-29 8:56 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 8:57 [PATCH v3 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 18:44 ` Greg KH
2014-05-28 18:44 ` Greg KH
[not found] ` <20140528184408.GC30031-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-05-29 8:56 ` Satish Patel [this message]
2014-05-29 8:56 ` Satish Patel
2014-05-29 8:56 ` Satish Patel
2014-05-29 15:51 ` Greg KH
2014-05-29 15:51 ` Greg KH
2014-05-30 5:05 ` Satish Patel
2014-05-30 5:05 ` Satish Patel
2014-05-30 5:05 ` Satish Patel
[not found] ` <1401267437-22489-2-git-send-email-satish.patel-l0cyMroinI0@public.gmane.org>
2014-05-28 18:53 ` Greg KH
2014-05-28 18:53 ` Greg KH
2014-05-28 18:53 ` Greg KH
2014-05-29 8:34 ` Satish Patel
2014-05-29 8:34 ` Satish Patel
2014-05-29 8:34 ` Satish Patel
[not found] ` <5386F0FE.7040003-l0cyMroinI0@public.gmane.org>
2014-05-29 13:47 ` Rob Herring
2014-05-29 13:47 ` Rob Herring
2014-05-29 13:47 ` Rob Herring
2014-05-29 15:52 ` Greg KH
2014-05-29 15:52 ` Greg KH
[not found] ` <CAL_Jsq+E7a=wh_yzQyaSEVAwfa34BYZ4DxvLOfJGFVDsf1dZ+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 3:51 ` Satish Patel
2014-05-30 3:51 ` Satish Patel
2014-05-30 3:51 ` Satish Patel
2014-05-28 8:57 ` [PATCH v3 2/5] misc: tda8026: Add NXP TDA8026 PHY driver Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` Satish Patel
[not found] ` <1401267437-22489-3-git-send-email-satish.patel-l0cyMroinI0@public.gmane.org>
2014-05-28 18:44 ` Greg KH
2014-05-28 18:44 ` Greg KH
2014-05-28 18:44 ` Greg KH
2014-05-29 8:37 ` Satish Patel
2014-05-29 8:37 ` Satish Patel
2014-05-29 8:37 ` Satish Patel
2014-05-29 15:52 ` Greg KH
2014-05-29 15:52 ` Greg KH
2014-05-28 8:57 ` [PATCH v3 3/5] char: ti-usim: Add driver for USIM module on AM43xx Satish Patel
2014-05-28 8:57 ` Satish Patel
[not found] ` <1401267437-22489-4-git-send-email-satish.patel-l0cyMroinI0@public.gmane.org>
2014-05-28 17:56 ` Rob Herring
2014-05-28 17:56 ` Rob Herring
[not found] ` <CAL_JsqKs=a8GRJRmNE-oxU4imHqnb5szv+Km-wv3KuN0d6Bxkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-29 10:05 ` Satish Patel
2014-05-29 10:05 ` Satish Patel
2014-05-29 15:53 ` Greg Kroah-Hartman
2014-05-29 15:53 ` Greg Kroah-Hartman
[not found] ` <20140529155349.GD32214-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-05-30 4:08 ` Satish Patel
2014-05-30 4:08 ` Satish Patel
2014-05-30 4:08 ` Satish Patel
2014-05-28 8:57 ` [PATCH v3 4/5] ARM: dts: AM43xx: DT entries added for ti-usim Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` [PATCH v3 5/5] ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy Satish Patel
2014-05-28 8:57 ` Satish Patel
2014-05-28 8:57 ` Satish Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5386F657.9040805@ti.com \
--to=satish.patel-l0cymroini0@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.