From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] ST SPEAr: PCIE gadget suppport
Date: Tue, 18 Jan 2011 15:51:47 +0100 [thread overview]
Message-ID: <201101181551.47675.arnd@arndb.de> (raw)
In-Reply-To: <4D2AEB84.6060804@st.com>
On Monday 10 January 2011, pratyush wrote:
> >> +/*wait till link is up*/
> >> +# cat sys/devices/platform/pcie-gadget-spear.0/link
> >> +wait till it returns UP.
> >
> > A blocking sysfs read is not a nice interface. This is probably where
> > the sysfs abstraction for your hardware stops making sense.
> >
>
> This call is not blocking. User will have to recheck link status till he
> finds it UP. He may put some delay between two successive read. I will
> modify documentation to be more explicit.
Ok, that is better, although with this interface you could argue that having
a blocking interface (not a sysfs file) would be useful to have.
> > The user interface for the interrupts looks to me like it should really
> > be based around a character device and either read/write/poll or
> > ioctl and poll. Using an eventfd might be cool here, because then you
> > can combine this with other devices by passing the event file to
> > an interface that operates on eventfd. This would e.g. make it possible
> > to combine a UIO device generating interrupts with a PCIe gadget
> > sending the interrupts somewhere else, without leaving kernel
> > space.
> >
>
> I do not have much idea about eventfd mechanism. But if we decide to
> split it in two layers (generic pcie gadget and HW specific) then I
> might try to do it in this way.
ok.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: pratyush <pratyush.anand@st.com>
Cc: Viresh KUMAR <viresh.kumar@st.com>, Greg KH <greg@kroah.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Shiraz HASHIM <shiraz.hashim@st.com>
Subject: Re: [PATCH V2] ST SPEAr: PCIE gadget suppport
Date: Tue, 18 Jan 2011 15:51:47 +0100 [thread overview]
Message-ID: <201101181551.47675.arnd@arndb.de> (raw)
In-Reply-To: <4D2AEB84.6060804@st.com>
On Monday 10 January 2011, pratyush wrote:
> >> +/*wait till link is up*/
> >> +# cat sys/devices/platform/pcie-gadget-spear.0/link
> >> +wait till it returns UP.
> >
> > A blocking sysfs read is not a nice interface. This is probably where
> > the sysfs abstraction for your hardware stops making sense.
> >
>
> This call is not blocking. User will have to recheck link status till he
> finds it UP. He may put some delay between two successive read. I will
> modify documentation to be more explicit.
Ok, that is better, although with this interface you could argue that having
a blocking interface (not a sysfs file) would be useful to have.
> > The user interface for the interrupts looks to me like it should really
> > be based around a character device and either read/write/poll or
> > ioctl and poll. Using an eventfd might be cool here, because then you
> > can combine this with other devices by passing the event file to
> > an interface that operates on eventfd. This would e.g. make it possible
> > to combine a UIO device generating interrupts with a PCIe gadget
> > sending the interrupts somewhere else, without leaving kernel
> > space.
> >
>
> I do not have much idea about eventfd mechanism. But if we decide to
> split it in two layers (generic pcie gadget and HW specific) then I
> might try to do it in this way.
ok.
Arnd
next prev parent reply other threads:[~2011-01-18 14:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 11:59 [PATCH V2] ST SPEAr: PCIE gadget suppport Viresh Kumar
2011-01-06 11:59 ` Viresh Kumar
2011-01-06 18:48 ` Greg KH
2011-01-06 18:48 ` Greg KH
2011-01-07 8:57 ` pratyush
2011-01-07 8:57 ` pratyush
2011-01-07 18:32 ` Greg KH
2011-01-07 18:32 ` Greg KH
2011-01-06 20:18 ` Andrew Morton
2011-01-06 20:18 ` Andrew Morton
2011-01-07 8:54 ` pratyush
2011-01-07 8:54 ` pratyush
2011-01-07 22:32 ` Arnd Bergmann
2011-01-07 22:32 ` Arnd Bergmann
2011-01-10 11:20 ` pratyush
2011-01-10 11:20 ` pratyush
2011-01-18 14:51 ` Arnd Bergmann [this message]
2011-01-18 14:51 ` Arnd Bergmann
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=201101181551.47675.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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.