All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Marek Vasut <marex@denx.de>,
	dsd@laptop.org, Andrzej Hajda <a.hajda@samsung.com>,
	David Airlie <airlied@linux.ie>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Pitre <nico@fluxnic.net>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	jfrederich@gmail.com, Robert Jarzmik <robert.jarzmik@free.fr>,
	Daniel Mack <daniel@zonque.org>
Subject: Re: [PATCH 7/8] fbdev: rework backlight dependencies
Date: Fri, 17 Apr 2020 21:55:43 +0200	[thread overview]
Message-ID: <CAK8P3a31OMHOycpGv5tjQXS=NBGw+OoFRGQ0Za7QWw9=EcwgZg@mail.gmail.com> (raw)
In-Reply-To: <20200417170444.GB30483@ravnborg.org>

On Fri, Apr 17, 2020 at 7:04 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Arnd.
>
> On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
> > Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> > make any driver that needs it have a dependency on the class device
> > being available, to prevent circular dependencies.
> >
> > This is the same way that the backlight is already treated for the DRM
> > subsystem.
>
> I am not happy with the direction of this patch.
> It is not easy to understand that one has to enable backlight to
> be allowed to select a display or an fbdev driver.
>
>
> How about somthing like this:
>
> config BACKLIGHT_CLASS_DEVICE
>         tristate
>         # Will enable backlight module
>         # Has no dependencies
>
> config  BACKLIGHT
>         bool "Backlight drivers"
>         # Will make the backlight drivers visible - a visibility option
>         # only
>
> All drivers outside video/backlight/ can then select
> BACKLIGHT_CLASS_DEVICE to get the backlight core
> module.
> Or in other words BACKLIGHT_CLASS_DEVICE is used as a sort
> of library symbol that gices us access to backlight functionality.

Right, this could work as long as nobody puts back any "depends on
BACKLIGHT_CLASS_DEVICE, but it does cause another problem: There
are a couple of drivers that can optionally use backlight support
or just leave it out depending on CONFIG_BACKLIGHT_CLASS_DEVICE.

Changing them to select the class device support unconditionally
would make it impossible to build those drivers without it.
Instead we could all need an individual Kconfig symbol, or use
have "select BACKLIGHT_CLASS_DEVICE if BACKLIGHT"
in each case, but I'm not sure if that's still a win over having a
simple 'depends on BACKLIGHT_CLASS_DEVICE'.

On a related note, the NEW_LEDS/LEDS_CLASS option probably
falls into the same category, and could also be done as you suggest.
At the moment, this has the problem that both symbols are user
visible and also frequently selected by device drivers (but not others),
which is causing another set of dependency issues.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Marek Vasut <marex@denx.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	dsd@laptop.org, Nicolas Pitre <nico@fluxnic.net>,
	David Airlie <airlied@linux.ie>,
	Masahiro Yamada <masahiroy@kernel.org>,
	jfrederich@gmail.com, Saeed Mahameed <saeedm@mellanox.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Jason Gunthorpe <jgg@ziepe.ca>, Daniel Mack <daniel@zonque.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 7/8] fbdev: rework backlight dependencies
Date: Fri, 17 Apr 2020 19:55:43 +0000	[thread overview]
Message-ID: <CAK8P3a31OMHOycpGv5tjQXS=NBGw+OoFRGQ0Za7QWw9=EcwgZg@mail.gmail.com> (raw)
In-Reply-To: <20200417170444.GB30483@ravnborg.org>

On Fri, Apr 17, 2020 at 7:04 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Arnd.
>
> On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
> > Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> > make any driver that needs it have a dependency on the class device
> > being available, to prevent circular dependencies.
> >
> > This is the same way that the backlight is already treated for the DRM
> > subsystem.
>
> I am not happy with the direction of this patch.
> It is not easy to understand that one has to enable backlight to
> be allowed to select a display or an fbdev driver.
>
>
> How about somthing like this:
>
> config BACKLIGHT_CLASS_DEVICE
>         tristate
>         # Will enable backlight module
>         # Has no dependencies
>
> config  BACKLIGHT
>         bool "Backlight drivers"
>         # Will make the backlight drivers visible - a visibility option
>         # only
>
> All drivers outside video/backlight/ can then select
> BACKLIGHT_CLASS_DEVICE to get the backlight core
> module.
> Or in other words BACKLIGHT_CLASS_DEVICE is used as a sort
> of library symbol that gices us access to backlight functionality.

Right, this could work as long as nobody puts back any "depends on
BACKLIGHT_CLASS_DEVICE, but it does cause another problem: There
are a couple of drivers that can optionally use backlight support
or just leave it out depending on CONFIG_BACKLIGHT_CLASS_DEVICE.

Changing them to select the class device support unconditionally
would make it impossible to build those drivers without it.
Instead we could all need an individual Kconfig symbol, or use
have "select BACKLIGHT_CLASS_DEVICE if BACKLIGHT"
in each case, but I'm not sure if that's still a win over having a
simple 'depends on BACKLIGHT_CLASS_DEVICE'.

On a related note, the NEW_LEDS/LEDS_CLASS option probably
falls into the same category, and could also be done as you suggest.
At the moment, this has the problem that both symbols are user
visible and also frequently selected by device drivers (but not others),
which is causing another set of dependency issues.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Marek Vasut <marex@denx.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	dsd@laptop.org, Nicolas Pitre <nico@fluxnic.net>,
	David Airlie <airlied@linux.ie>,
	Masahiro Yamada <masahiroy@kernel.org>,
	jfrederich@gmail.com, Saeed Mahameed <saeedm@mellanox.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Jason Gunthorpe <jgg@ziepe.ca>, Daniel Mack <daniel@zonque.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 7/8] fbdev: rework backlight dependencies
Date: Fri, 17 Apr 2020 21:55:43 +0200	[thread overview]
Message-ID: <CAK8P3a31OMHOycpGv5tjQXS=NBGw+OoFRGQ0Za7QWw9=EcwgZg@mail.gmail.com> (raw)
In-Reply-To: <20200417170444.GB30483@ravnborg.org>

On Fri, Apr 17, 2020 at 7:04 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Arnd.
>
> On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
> > Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> > make any driver that needs it have a dependency on the class device
> > being available, to prevent circular dependencies.
> >
> > This is the same way that the backlight is already treated for the DRM
> > subsystem.
>
> I am not happy with the direction of this patch.
> It is not easy to understand that one has to enable backlight to
> be allowed to select a display or an fbdev driver.
>
>
> How about somthing like this:
>
> config BACKLIGHT_CLASS_DEVICE
>         tristate
>         # Will enable backlight module
>         # Has no dependencies
>
> config  BACKLIGHT
>         bool "Backlight drivers"
>         # Will make the backlight drivers visible - a visibility option
>         # only
>
> All drivers outside video/backlight/ can then select
> BACKLIGHT_CLASS_DEVICE to get the backlight core
> module.
> Or in other words BACKLIGHT_CLASS_DEVICE is used as a sort
> of library symbol that gices us access to backlight functionality.

Right, this could work as long as nobody puts back any "depends on
BACKLIGHT_CLASS_DEVICE, but it does cause another problem: There
are a couple of drivers that can optionally use backlight support
or just leave it out depending on CONFIG_BACKLIGHT_CLASS_DEVICE.

Changing them to select the class device support unconditionally
would make it impossible to build those drivers without it.
Instead we could all need an individual Kconfig symbol, or use
have "select BACKLIGHT_CLASS_DEVICE if BACKLIGHT"
in each case, but I'm not sure if that's still a win over having a
simple 'depends on BACKLIGHT_CLASS_DEVICE'.

On a related note, the NEW_LEDS/LEDS_CLASS option probably
falls into the same category, and could also be done as you suggest.
At the moment, this has the problem that both symbols are user
visible and also frequently selected by device drivers (but not others),
which is causing another set of dependency issues.

      Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-17 19:56 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 15:55 [PATCH 0/8] drm, fbdev: rework dependencies Arnd Bergmann
2020-04-17 15:55 ` Arnd Bergmann
2020-04-17 15:55 ` Arnd Bergmann
2020-04-17 15:55 ` [PATCH 1/8] fbdev: w100fb: clean up mach-pxa compile-time dependency Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-18 10:10   ` Robert Jarzmik
2020-04-18 10:10     ` Robert Jarzmik
2020-04-18 10:10     ` Robert Jarzmik
2020-04-18 10:14     ` Arnd Bergmann
2020-04-18 10:14       ` Arnd Bergmann
2020-04-18 10:14       ` Arnd Bergmann
2020-04-17 15:55 ` [PATCH 2/8] fbdev/ARM: pxa: avoid selecting CONFIG_FB Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-18 10:18   ` Robert Jarzmik
2020-04-18 10:18     ` Robert Jarzmik
2020-04-18 10:18     ` Robert Jarzmik
2020-04-17 15:55 ` [PATCH 3/8] fbdev: rework FB_DDC dependencies Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55 ` [PATCH 4/8] drm/rcar: stop using 'imply' for dependencies Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55 ` [PATCH 5/8] drm/vmwgfx: make framebuffer support optional Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-20 12:07   ` Thomas Zimmermann
2020-04-20 12:07     ` Thomas Zimmermann
2020-04-20 12:07     ` Thomas Zimmermann
2020-04-17 15:55 ` [PATCH 6/8] drm: decouple from CONFIG_FB Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 16:50   ` Sam Ravnborg
2020-04-17 16:50     ` Sam Ravnborg
2020-04-17 16:50     ` Sam Ravnborg
2020-04-17 20:03     ` Arnd Bergmann
2020-04-17 20:03       ` Arnd Bergmann
2020-04-17 20:03       ` Arnd Bergmann
2020-04-17 20:29       ` Sam Ravnborg
2020-04-17 20:29         ` Sam Ravnborg
2020-04-17 20:29         ` Sam Ravnborg
2020-04-17 15:55 ` [PATCH 7/8] fbdev: rework backlight dependencies Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 17:04   ` Sam Ravnborg
2020-04-17 17:04     ` Sam Ravnborg
2020-04-17 17:04     ` Sam Ravnborg
2020-04-17 19:55     ` Arnd Bergmann [this message]
2020-04-17 19:55       ` Arnd Bergmann
2020-04-17 19:55       ` Arnd Bergmann
2020-04-20  8:02     ` Jani Nikula
2020-04-20  8:02       ` Jani Nikula
2020-04-20  8:02       ` Jani Nikula
2020-04-17 15:55 ` [PATCH 8/8] drm/bridge/sii8620: fix extcon dependency Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 15:55   ` Arnd Bergmann
2020-04-17 16:52   ` Andrzej Hajda
2020-04-17 16:52     ` Andrzej Hajda
2020-04-17 16:52     ` Andrzej Hajda
2020-04-17 17:14 ` [PATCH 0/8] drm, fbdev: rework dependencies Daniel Vetter
2020-04-17 17:14   ` Daniel Vetter
2020-04-17 17:14   ` Daniel Vetter
2020-04-17 19:08   ` Jason Gunthorpe
2020-04-17 19:08     ` Jason Gunthorpe
2020-04-17 19:08     ` Jason Gunthorpe
2020-04-20  8:14     ` Jani Nikula
2020-04-20  8:14       ` Jani Nikula
2020-04-20  8:14       ` Jani Nikula
2020-04-20 14:03       ` Arnd Bergmann
2020-04-20 14:03         ` Arnd Bergmann
2020-04-20 14:03         ` Arnd Bergmann
2020-04-21 12:27         ` Daniel Vetter
2020-04-21 12:27           ` Daniel Vetter
2020-04-21 12:27           ` Daniel Vetter
2020-04-21 12:58           ` Jani Nikula
2020-04-21 12:58             ` Jani Nikula
2020-04-21 12:58             ` Jani Nikula
2020-04-21 13:05             ` Geert Uytterhoeven
2020-04-21 13:05               ` Geert Uytterhoeven
2020-04-21 13:05               ` Geert Uytterhoeven
2020-04-21 13:10               ` Daniel Vetter
2020-04-21 13:10                 ` Daniel Vetter
2020-04-21 13:10                 ` Daniel Vetter
2020-04-21 13:25                 ` Jani Nikula
2020-04-21 13:25                   ` Jani Nikula
2020-04-21 13:25                   ` Jani Nikula

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='CAK8P3a31OMHOycpGv5tjQXS=NBGw+OoFRGQ0Za7QWw9=EcwgZg@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=daniel@zonque.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dsd@laptop.org \
    --cc=geert@linux-m68k.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=jfrederich@gmail.com \
    --cc=jgg@ziepe.ca \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=masahiroy@kernel.org \
    --cc=nico@fluxnic.net \
    --cc=robert.jarzmik@free.fr \
    --cc=saeedm@mellanox.com \
    --cc=sam@ravnborg.org \
    --cc=thellstrom@vmware.com \
    /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.