[PATCH 05/11] ALSA: make WM8753 driver a new-style I2C driver

Jonas Bonn jonas.bonn at gmail.com
Wed Oct 1 19:19:42 CEST 2008

I can check if the sound patches can be put into the sound-2.6 tree
instead... that way we'll get them when we rebase later.  I can also
check if we cherry-pick them into our OpenMoko tree now, too... I
think that should be doable.
Are we certain that the topic/asoc branch is headed for upstream in 2.6.28?

On Wed, Oct 1, 2008 at 6:54 PM, Andy Green <andy at openmoko.com> wrote:
> Hash: SHA1
> Somebody in the thread at some point said:
> |> For now I guess we will take Jonas' stuff and rebase it out when Jean's
> |> accepted stuff comes in from upstream, it's a headache either way.
> |
> | TBH I'm not clear what benefit there is from doing these changes in the
> | OpenMoko tree is - the net effect of the two registration APIs is the
> It's simply that I can take the patchset and move on.  I tried removing
> 5/11 but at least 7/11 depends on it and I don't have time to unpick the
> intentions.
> | same, it should just be a code cleanup change.  If there were an
> | immediate benefit from doing the conversion or if it hadn't yet been
> | done upstream and could therefore be pushed upstream it'd make sense to
> | me but that's not the case here.
> |
> | Note that this doesn't apply to the reordering of the scenario setup
> | which is a straight bugfix independant of the I2C API changes (ASoC got
> | better at pointing out when stuff goes wrong).
> Jonas, what do you think about Mark's points?  If you can decouple the
> later patches from this conflicting stuff it will save headaches later
> (and now).
> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> iEYEARECAAYFAkjjqzUACgkQOjLpvpq7dMqA6gCfWvZ78p9h5wMDFEAKocrWEmSs
> cpIAn2abMruLJV+MYHjyG4ssurKkDE5J
> =TD2W

Jonas Bonn
Stockholm, Sweden

More information about the openmoko-kernel mailing list