From: Jonathan Cameron <jic23@cam.ac.uk>
To: "Hennerich, Michael" <Michael.Hennerich@analog.com>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
Drivers <Drivers@analog.com>,
"device-drivers-devel@blackfin.uclinux.org"
<device-drivers-devel@blackfin.uclinux.org>
Subject: Re: [Device-drivers-devel] [PATCH] IIO: DDS: Remove deficient drivers.
Date: Mon, 21 Mar 2011 13:49:42 +0000 [thread overview]
Message-ID: <4D875776.7050008@cam.ac.uk> (raw)
In-Reply-To: <544AC56F16B56944AEC3BD4E3D591771375431588C@LIMKCMBX1.ad.analog.com>
On 03/21/11 13:15, Hennerich, Michael wrote:
> Mike Frysinger wrote on 2011-03-21:
>> On Mon, Mar 21, 2011 at 08:56, <michael.hennerich@analog.com> wrote:
>>> From: Michael Hennerich <michael.hennerich@analog.com>
>>>
>>> These drivers don't conform with the API for such devices.
>>> Therefore they are temporarily removed until they are fixed up
>> anytime later.
>>
>> this is the staging tree ... wouldnt it be easier to leave them alone
>> until they get fixed ?
>> -mike
>
> We want to move out of staging in the near future.
> There is no simple fix for them. A fix is to rewrite them from scratch.
> The only thing in common a fixed driver would share with the existing one, is the file name.
> No point in keeping them as bad examples.
Your call I guess. Though the move out of staging is going to leave quite
a few drivers behind in the first instance anyway so I wouldn't worry about that.
Usual staging removal cases are:
1) It doesn't work and no one cares (no idea)
2) No one is working on it (arguably true here)
3) It's been replaced by something better (not yet)
The move is probably going to be more a case of submitting a fresh parallel version
of the core to mainline, then porting individual drivers across.
The issues raised by Arnd for starters are going to cause quite a few changes (and
he's just the first person from outside of normal IIO people to take a look).
I'll keep the old core api's in the staging version, but we won't want them in
the non staging version.
In the short term I'm working on a set that will completely change how the sysfs
stuff is registered. Not entirely convinced it is the way to go yet, but it does
look fairly promising. If we do decide to go with that, in some form, I don't
propose moving the whole driver set over to it before we start moving out of staging.
Jonathan
prev parent reply other threads:[~2011-03-21 13:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 12:56 [PATCH] IIO: DDS: Remove deficient drivers michael.hennerich
2011-03-21 13:07 ` [Device-drivers-devel] " Mike Frysinger
2011-03-21 13:15 ` Hennerich, Michael
2011-03-21 13:49 ` Jonathan Cameron [this message]
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=4D875776.7050008@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=Drivers@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=linux-iio@vger.kernel.org \
--cc=vapier.adi@gmail.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 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.