From: Greg KH <gregkh@linuxfoundation.org>
To: Satish Patel <satish.patel@ti.com>
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 08:51:22 -0700 [thread overview]
Message-ID: <20140529155122.GA32214@kroah.com> (raw)
In-Reply-To: <5386F657.9040805@ti.com>
On Thu, May 29, 2014 at 02:26:55PM +0530, Satish Patel wrote:
>
>
> 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 ?
No, use the device itself.
> 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.
Ick, no, that's not how the driver model works. Each device in the
system needs a struct device, don't try to "chain" off of an existing
device like this. Make it a "real" one.
> >>+
> >>+ /* 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..
That doesn't make much sense to me, why not just put that in the notify
function callback itself?
Please either use the existing phy layer of the kernel, or make a "real"
subsystem here, don't try to put a tiny shim on top of an existing
struct device for this driver, that's not how subsystems in Linux are
done.
thanks,
greg k-h
next prev parent reply other threads:[~2014-05-29 15:51 UTC|newest]
Thread overview: 22+ 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 ` [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller Satish Patel
2014-05-28 18:44 ` Greg KH
[not found] ` <20140528184408.GC30031-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-05-29 8:56 ` Satish Patel
2014-05-29 15:51 ` Greg KH [this message]
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-29 8:34 ` Satish Patel
[not found] ` <5386F0FE.7040003-l0cyMroinI0@public.gmane.org>
2014-05-29 13:47 ` Rob Herring
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-28 8:57 ` [PATCH v3 2/5] misc: tda8026: Add NXP TDA8026 PHY driver 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-29 8:37 ` Satish Patel
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
[not found] ` <1401267437-22489-4-git-send-email-satish.patel-l0cyMroinI0@public.gmane.org>
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 15:53 ` Greg Kroah-Hartman
[not found] ` <20140529155349.GD32214-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
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 ` [PATCH v3 5/5] ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy 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=20140529155122.GA32214@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=satish.patel@ti.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).