From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
alsa-devel@alsa-project.org,
Pierre-Louis Bossart <pierre-louis.bossart@intel.com>,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH 0/2] ASoC: SOF: initialise work immediately
Date: Tue, 24 Mar 2020 14:58:56 +0100 [thread overview]
Message-ID: <20200324135856.GA29623@ubuntu> (raw)
In-Reply-To: <20200324133042.GB7039@sirena.org.uk>
Hi Mark,
On Tue, Mar 24, 2020 at 01:30:42PM +0000, Mark Brown wrote:
> On Tue, Mar 24, 2020 at 01:29:19PM +0100, Guennadi Liakhovetski wrote:
> > Fix uninitialised work errors by moving initialisation to directly
> > after allocation.
> >
> > Guennadi Liakhovetski (2):
> > ASoC: SOF: (cosmetic) use for_each_pcm_streams() in sof_dai_load()
> > ASoC: SOF: fix uninitialised "work" with VirtIO
>
> As documented in submitting-patches.rst please send patches to the
> maintainers for the code you would like to change. The normal kernel
> workflow is that people apply patches from their inboxes, if they aren't
> copied they are likely to not see the patch at all and it is much more
> difficult to apply patches.
I know that different maintainers have different preferences. For example
in the subsysteem, where I'd worked for about 10 years the maintainer
preferred not to be CCed on patches, he preferred to pick up patches from
his mailing list folders, or whatever arrangement his mail filters
provided for. I learned already that in ALSA / ASoC it's usual to CC
maintainers. But I wasn't sure whether that also holds for larger patch
series. E.g. my main patch series now consists of 14 patches, so, I
thought, that maybe you would rather not receive multiple copies of the
entire seriees for each new version both directly in your inbox and in
the mailing list folder. Or is it indeed your preference to always be
CCed on all patches? I apologise for re-iterating a question, that
probably had been addressed multiple times before, maybe it's worth
documenting this somewhere on ALSA web?
Thanks
Guennadi
next prev parent reply other threads:[~2020-03-24 14:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 12:29 [PATCH 0/2] ASoC: SOF: initialise work immediately Guennadi Liakhovetski
2020-03-24 12:29 ` [PATCH 1/2] ASoC: SOF: (cosmetic) use for_each_pcm_streams() in sof_dai_load() Guennadi Liakhovetski
2020-03-24 13:29 ` Pierre-Louis Bossart
2020-03-24 14:06 ` Guennadi Liakhovetski
2020-03-24 12:29 ` [PATCH 2/2] ASoC: SOF: fix uninitialised "work" with VirtIO Guennadi Liakhovetski
2020-03-24 13:30 ` [PATCH 0/2] ASoC: SOF: initialise work immediately Mark Brown
2020-03-24 13:58 ` Guennadi Liakhovetski [this message]
2020-03-24 14:48 ` Mark Brown
2020-03-25 11:10 ` Guennadi Liakhovetski
2020-03-25 11:10 ` Guennadi Liakhovetski
2020-03-25 11:20 ` 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=20200324135856.GA29623@ubuntu \
--to=guennadi.liakhovetski@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=pierre-louis.bossart@intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.de \
/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.