From: Olof Johansson <olof@lixom.net>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
voice.shen@atmel.com,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
linux-sound@vger.kernel.org
Subject: Re: [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8
Date: Fri, 11 Jan 2013 11:53:31 -0800 [thread overview]
Message-ID: <20130111195331.GA2533@quad.lixom.net> (raw)
In-Reply-To: <20130111193948.GA8677@opensource.wolfsonmicro.com>
On Fri, Jan 11, 2013 at 07:39:49PM +0000, Mark Brown wrote:
> On Fri, Jan 11, 2013 at 10:52:19AM -0800, Olof Johansson wrote:
> > On Fri, Jan 11, 2013 at 6:08 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> >
> > > This material was designed to enter Mark's fixes queue, but as discussed with
> > > Olof, we can imagine merging everything through arm-soc or split the series (of
> > > 2 patches) and let them progress upstream separated (option that I do not like
> > > even if I know that the consequences are not so dramatic).
> > > So please, Olof, if you feel confortable with this series, tell us what you
> > > prefer and we will make our best to make this material go forward...
>
> > You're setting yourself up for awkward merges. The driver change is
> > strongly dependent on the device tree change by failing probe unless
> > the device tree update is there, while before this patch, it still
> > worked.
>
> This is partly my fault for getting grumpy about adding the bolier plate
> code without error checking - overall Linus' change to do the get in the
> core seems like the most sane approach here.
>
> > But to be honest, I don't think this is a fix, it's a feature that you
> > just didn't include in time for the merge window. I don't really see
> > them as appropriate 3.8 material at this point.
>
> Jean-Christophe has been most insistent that pinctrl support is now
> manadatory for all AT91 systems using device tree.
That's a noble goal but enforcing it early gives everyone a lot of pain, and
quite honestly doesn't make sense. During transition it's better to be lenient
and allow both old and new methods (without breakage), unless it causes
significant extra churn.
> Unfortunately
> pinctrl support for AT91 only came in during the merge window and it
> seems like it's sadly been impossible to do what seemd like the obvious
> thing and add the pinctrl bindings to the DT prior to the merge down so
> now we've got this mess. I believe the way the pinctrl conversion was
> done renders the audio driver non-functional without this series.
The problem is that at91 tries to do too much in a single release, and then do
nothing in several releases after. If there was a steadier trickle of code
coming in, then these kind of complex dependencies wouldn't show up all at
once, and could be handled with much less overhead for everyone else involved.
:(
>
> > So, nack on this series. Please make the driver change non-dependent
> > on the new dtsi contents, and merge that through the ASoC tree. Then
> > the dtsi update can go through arm-soc, and later on you can make it
> > mandatory.
>
> Like I say I'm not thrilled about ignoring the return code TBH, nor am I
> thrilled with the way this has been handled overall. That said, the
> current series does seem like the best of a bad job - as I understand it
> we need something like this in v3.8 to make the driver functional.
To be honest, if Atmel can't figure out how to merge a complete feature
without causing intentional regressions during the merge window, and plan
on brokenness to be fixed as late as in -rc4, then they deserve to have
a broken platform. Unfortunately the victim of that is end users, and we
don't want to leave them hanging. This really can't become a trend though.
Sigh. Feel free to add:
Reluctantly-acked-by: Olof Johansson <olof@lixom.net>
to the patches when you apply them (based on IRC discussion, might as
well take both through ASoC).
-Olof
next prev parent reply other threads:[~2013-01-11 19:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 14:08 [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8 Nicolas Ferre
2013-01-11 14:08 ` [PATCH 1/2 v2] ARM: at91/dts: add pinctrl support for SSC peripheral Nicolas Ferre
2013-01-11 14:08 ` [PATCH 2/2 v2] ASoC: atmel-ssc: add pinctrl selection to driver Nicolas Ferre
2013-01-11 18:52 ` [PATCH 0/2 v2] at91/ssc: fixes on ASoC tree for 3.8 Olof Johansson
2013-01-11 19:39 ` Mark Brown
2013-01-11 19:53 ` Olof Johansson [this message]
2013-01-12 13:34 ` Jean-Christophe PLAGNIOL-VILLARD
2013-01-12 0:04 ` Mark Brown
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=20130111195331.GA2533@quad.lixom.net \
--to=olof@lixom.net \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.com \
--cc=voice.shen@atmel.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