Linux I2C development
 help / color / mirror / Atom feed
From: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: legacy drivers in staging?
Date: Sun, 1 Mar 2009 20:26:15 +0100	[thread overview]
Message-ID: <20090301192615.GB24892@pengutronix.de> (raw)
In-Reply-To: <20090301113641.33a462d2-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

Hi Jean,

> I am not sure myself. I agree we don't want to delay the removal of the
> legacy binding just because of these drivers. But OTOH I see little
> point in having a staging directory [1] if drivers being placed there
> break as soon as there is a core kernel change. I guess we are supposed
> to update these drivers as we do for all other drivers.

My view is a bit like the comment found in staging/rt28[67]0/TODO:

===

Please send any patches or complaints about this driver to Greg
Kroah-Hartman <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> and don't bother the upstream wireless
kernel developers about it, they want nothing to do with it.

===

> That being said I think that there is much more work needed on these
> drivers, on the V4L side.

As some of these drivers are not just ugly but also conceptually wrong
(epl for example), I would vote for not accepting any duties which come
from them. Especially when it is a long awaited task like the removal of
the legacy binding.

> Bottom line is that, is these drivers are the last ones blocking the
> removal of the legacy i2c driver, I will either attempt to convert them
> the quick-and-dirty way, or I will mark them as broken and leave it to
> somebody else to fix them. They will not delay us.

That is nice to hear. I don't think you need to mark them as broken,
staging is per se broken :) And please don't spend time on fixing them ;)

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

      parent reply	other threads:[~2009-03-01 19:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01 10:13 legacy drivers in staging? Wolfram Sang
     [not found] ` <20090301101306.GB23093-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-03-01 10:36   ` Jean Delvare
     [not found]     ` <20090301113641.33a462d2-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-03-01 19:26       ` Wolfram Sang [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=20090301192615.GB24892@pengutronix.de \
    --to=w.sang-bicnvbalz9megne8c9+irq@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox