Re: [PATCH 01/10] backlight: Add backlight_device_get_by_name()

[Lee Jones <lee.jones@linaro.org>]

On Thu, 30 Apr 2020, Daniel Vetter wrote:

> On Thu, Apr 30, 2020 at 11:15:29AM +0100, Lee Jones wrote:
> > On Thu, 30 Apr 2020, Noralf Trønnes wrote:
> > 
> > > 
> > > 
> > > Den 30.04.2020 10.32, skrev Lee Jones:
> > > > On Wed, 29 Apr 2020, Noralf Trønnes wrote:
> > > > 
> > > >> Add a way to lookup a backlight device based on its name.
> > > >> Will be used by a USB display gadget getting the name from configfs.
> > > >>
> > > >> Cc: Lee Jones <lee.jones@linaro.org>
> > > >> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > >> Cc: Jingoo Han <jingoohan1@gmail.com>
> > > >> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
> > > >> ---
> > > >>  drivers/video/backlight/backlight.c | 21 +++++++++++++++++++++
> > > >>  include/linux/backlight.h           |  1 +
> > > >>  2 files changed, 22 insertions(+)
> > > > 
> > > > Once reviewed, can this patch be applied on its own?
> > > > 
> > > 
> > > If you can apply it for 5.8, then we're good. DRM has cutoff at -rc5 and
> > > the driver won't be ready for that. This patch has this dependency
> > > chain: usb -> drm -> backlight. So if you can apply it for 5.8, things
> > > gets easier.
> > > 
> > > > My guess is that it can't, as the other patches in this set depend on
> > > > it, right?  If this assumption is true, you need to send me the rest
> > > > of the set.
> > > > 
> > > > FYI: It's normally better to send the whole set to everyone, as it
> > > > provides visibility on current review (or lack there of) status of the
> > > > other patches and allows each of the maintainers to discuss possible
> > > > merge strategies.
> 
> Unfortunately this doesn't hold universally, since once you cc too many
> people smtp servers start throwing your mails away. Generally only happens
> for bigger refactorings, so pretty much anyone working cross-tree doesn't
> do this because it doesn't work.

I haven't experienced issues with SMTP servers.  Although I am aware
of a few mailing lists that are configured to require moderator
intervention if the recipient list reaches a given length.

> > > dri-devel is the ML for backlight so I assumed you got the full set.
> > 
> > dri-devel isn't the ML for Backlight.  It's an interested party.
> > 
> > I certainly have no intention of subscribing to it.
> 
> dri-devel is on lore so that you can grab missing patches. No need to
> subscribe. I've only manged to get this sorted recently (last autumn or
> so), but it's finally done.

This is helpful.  Thanks for doing the work required to make this
happen.  It's still infinitely more convenient to have the full set
in my inbox available for review.  As someone who works cross-
subsystem a lot, I can tell you that it works well in the vast
majority of cases.

Maybe just add the listed (in 'MAINTAINERS') maintainers and possibly
the reviewers.  Obviously all of the secondary interested parties that
get_maintainer.pl recommends should be omitted.

> > > I have had trouble in the past with my email provider dropping parts of
> > > a series when I had to many recipients.
> > 
> > Without visibility into the other patches in the set, things become
> > more difficult.  Maybe use a different/better email provider.

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