lkml.org 
[lkml]   [2020]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
    On Tue, 15 Dec 2020, ChiYuan Huang wrote:

    > Hi, Lee:
    >
    > Lee Jones <lee.jones@linaro.org> 於 2020年12月15日 週二 下午3:53寫道:
    > >
    > > On Mon, 14 Dec 2020, Daniel Thompson wrote:
    > >
    > > > On Mon, Dec 14, 2020 at 10:40:55PM +0800, ChiYuan Huang wrote:
    > > > > Hi,
    > > > >
    > > > > Daniel Thompson <daniel.thompson@linaro.org> 於 2020年12月14日 週一 下午5:59寫道:
    > > > > >
    > > > > > Hi CY
    > > > > >
    > > > > > On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote:
    > > > > > > From: ChiYuan Huang <cy_huang@richtek.com>
    > > > > > >
    > > > > > > Adds DT binding document for Richtek RT4831 backlight.
    > > > > > >
    > > > > > > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
    > > > > >
    > > > > > This patch got keyword filtered and brought to my attention
    > > > > > but the rest of the series did not.
    > > > > >
    > > > > > If it was a backlight patch series you need to send it To: the
    > > > > > all the backlight maintainers.
    > > > > >
    > > > > Yes, I'm waiting for mfd reviewing.
    > > > > Due to mfd patch, I need to add backlight dt-binding patch prior to
    > > > > backlight source code.
    > > > > Or autobuild robot will said mfd dt-binding build fail from Rob.
    > > > > That's why I send the backlight dt-binding prior to the source code.
    > > > >
    > > > > I still have backlight/regulator source code patch after mfd reviewing.
    > > > > Do you want me to send all the patches without waiting for mfd reviewing?
    > > >
    > > > To some extent it's up to you.
    > > >
    > > > I think I would have shared all the pieces at once (although not it Lee,
    > > > as mfd maintainer, had suggested otherwise).
    > >
    > > You should not need to concern yourself with patch ordering outside
    > > of the realms of the set i.e. [PATCH 1/x], [PATCH 2/x], etc.
    > >
    > > If you just send the whole patch set and you do not specify otherwise,
    > > it will be applied, in order, as a set.
    > >
    > > Sending subsystem patches without the correct maintainers as recipients
    > > is bad form. Many of us have filters on, so this tactic will seldom
    > > work in any case.
    > >
    >
    > In my case, there're mfd/backlight/regulator for RT4831.
    > You mean I can just send the whole patch set directly to whole
    > mfd/backlight/regulator maintainers.
    > And you can filter like as the keyword to review the related contents, right?
    >
    > From my original thought, the order is mfd -> backlight-> regulator,
    > one by one due to different maintainers.
    > Maybe I think too much about the patch ordering
    >
    > If so, after getting the comment from Rob, I'll send the whole patch to you.
    > Thanks for the notice.

    Simply send them all as a single patch-set. It's a good idea to add
    all maintainers to all patches. We will then coordinate amongst
    ourselves and come up with the best merge strategy.

    --
    Lee Jones [李琼斯]
    Senior Technical Lead - Developer Services
    Linaro.org │ Open source software for Arm SoCs
    Follow Linaro: Facebook | Twitter | Blog

    \
     
     \ /
      Last update: 2020-12-15 10:26    [W:6.358 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site