| Message ID | 20181024045653.GA2864@v (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] staging: mt7621-dma: Add braces around else branches | expand |
Hi Kiberly, Thanks for adding all the emails in CC. I would encourage you for your next patch to distinguish between CC and TO. You should send your patch TO important maintainers in the get_maintainers.pl list (as default, to all of them). If there is someone you really want to look into the patch, then add him/her in TO as well. Put the rest (people and mailing lists) in CC. Why? Some people filter their mails so that they can concentrate on the mails they got send directly and look on mails they are in CC with lower priority (maybe not at all, because there are too much?). So it is important to have the maintainers in the TO list and not in CC. Keep up the good work :) Matthias On 24/10/2018 06:56, Kimberly Brown wrote: > Add braces around else branches in conditional statements that include > branches with multiple statements. This style complies with the Linux > kernel coding style and improves consistency and readability. Issues found by > checkpatch. > > Signed-off-by: Kimberly Brown <kimbrownkd@gmail.com> > Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> > --- > Changes in v2: > - Added people and mailing lists from get_maintainer.pl to the CC list > - Added Reviewed-by line > > drivers/staging/mt7621-dma/mtk-hsdma.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c b/drivers/staging/mt7621-dma/mtk-hsdma.c > index df6ebf41bdea..35556f024aa1 100644 > --- a/drivers/staging/mt7621-dma/mtk-hsdma.c > +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c > @@ -418,8 +418,9 @@ static void mtk_hsdma_chan_done(struct mtk_hsdam_engine *hsdma, > vchan_cookie_complete(&desc->vdesc); > chan_issued = gdma_next_desc(chan); > } > - } else > + } else { > dev_dbg(hsdma->ddev.dev, "no desc to complete\n"); > + } > > if (chan_issued) > set_bit(chan->id, &hsdma->chan_issued); > @@ -456,8 +457,9 @@ static void mtk_hsdma_issue_pending(struct dma_chan *c) > if (gdma_next_desc(chan)) { > set_bit(chan->id, &hsdma->chan_issued); > tasklet_schedule(&hsdma->task); > - } else > + } else { > dev_dbg(hsdma->ddev.dev, "no desc to issue\n"); > + } > } > spin_unlock_bh(&chan->vchan.lock); > } >
On Wed, Oct 24, 2018 at 12:45:44PM +0200, Matthias Brugger wrote: > Hi Kiberly, > > Thanks for adding all the emails in CC. > I would encourage you for your next patch to distinguish between CC and TO. > You should send your patch TO important maintainers in the get_maintainers.pl > list (as default, to all of them). If there is someone you really want to look > into the patch, then add him/her in TO as well. > > Put the rest (people and mailing lists) in CC. Why? Some people filter their > mails so that they can concentrate on the mails they got send directly and look > on mails they are in CC with lower priority (maybe not at all, because there are > too much?). So it is important to have the maintainers in the TO list and not in CC. +1 I'm glad that there's someone else in the Linux community that agrees with me on this point, and is willing to speak out about it.
On Wed, Oct 24, 2018 at 12:45:44PM +0200, Matthias Brugger wrote: > Hi Kiberly, > > Thanks for adding all the emails in CC. > I would encourage you for your next patch to distinguish between CC and TO. > You should send your patch TO important maintainers in the get_maintainers.pl > list (as default, to all of them). If there is someone you really want to look > into the patch, then add him/her in TO as well. > I normally just add the first person from get_maintainer.pl to the To:. It's basically random I think. The rest I put in the CC. This is a staging patch so no one is very picky. There isn't a Fixes tag for this but if there were I add the person who wrote the original patch to the To header. Hopefully, they review and Ack my patch. I feel like that's very important. regards, dan carpenter
On Wed, 24 Oct 2018, Russell King - ARM Linux wrote: > On Wed, Oct 24, 2018 at 12:45:44PM +0200, Matthias Brugger wrote: > > Hi Kiberly, > > > > Thanks for adding all the emails in CC. > > I would encourage you for your next patch to distinguish between CC and TO. > > You should send your patch TO important maintainers in the get_maintainers.pl > > list (as default, to all of them). If there is someone you really want to look > > into the patch, then add him/her in TO as well. > > > > Put the rest (people and mailing lists) in CC. Why? Some people filter their > > mails so that they can concentrate on the mails they got send directly and look > > on mails they are in CC with lower priority (maybe not at all, because there are > > too much?). So it is important to have the maintainers in the TO list and not in CC. > > +1 > > I'm glad that there's someone else in the Linux community that agrees > with me on this point, and is willing to speak out about it. If it's an important point, perhaps it should be mentioned in submitting-patches.rst? There is a mention of the Cc tag, but no indication of who to put in CC. julia
On Wed, Oct 24, 2018 at 02:06:18PM +0100, Julia Lawall wrote: > > > On Wed, 24 Oct 2018, Russell King - ARM Linux wrote: > > > On Wed, Oct 24, 2018 at 12:45:44PM +0200, Matthias Brugger wrote: > > > Hi Kiberly, > > > > > > Thanks for adding all the emails in CC. > > > I would encourage you for your next patch to distinguish between CC and TO. > > > You should send your patch TO important maintainers in the get_maintainers.pl > > > list (as default, to all of them). If there is someone you really want to look > > > into the patch, then add him/her in TO as well. > > > > > > Put the rest (people and mailing lists) in CC. Why? Some people filter their > > > mails so that they can concentrate on the mails they got send directly and look > > > on mails they are in CC with lower priority (maybe not at all, because there are > > > too much?). So it is important to have the maintainers in the TO list and not in CC. > > > > +1 > > > > I'm glad that there's someone else in the Linux community that agrees > > with me on this point, and is willing to speak out about it. > > If it's an important point, perhaps it should be mentioned in > submitting-patches.rst? There is a mention of the Cc tag, but no > indication of who to put in CC. submitting-patches.rst talks about the Cc tag in the commit, not the To or Cc in the email client. In any case, there's a lot of personal issues here: most kernel developers don't care whether they're in the To or Cc header of an email, but there are some who do use it as Matthias says - which is actually the long-standing definition of these headers.
diff --git a/drivers/staging/mt7621-dma/mtk-hsdma.c b/drivers/staging/mt7621-dma/mtk-hsdma.c index df6ebf41bdea..35556f024aa1 100644 --- a/drivers/staging/mt7621-dma/mtk-hsdma.c +++ b/drivers/staging/mt7621-dma/mtk-hsdma.c @@ -418,8 +418,9 @@ static void mtk_hsdma_chan_done(struct mtk_hsdam_engine *hsdma, vchan_cookie_complete(&desc->vdesc); chan_issued = gdma_next_desc(chan); } - } else + } else { dev_dbg(hsdma->ddev.dev, "no desc to complete\n"); + } if (chan_issued) set_bit(chan->id, &hsdma->chan_issued); @@ -456,8 +457,9 @@ static void mtk_hsdma_issue_pending(struct dma_chan *c) if (gdma_next_desc(chan)) { set_bit(chan->id, &hsdma->chan_issued); tasklet_schedule(&hsdma->task); - } else + } else { dev_dbg(hsdma->ddev.dev, "no desc to issue\n"); + } } spin_unlock_bh(&chan->vchan.lock); }