All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: dri-devel@lists.freedesktop.org,
	Jani Nikula <jani.nikula@linux.intel.com>,
	linux-fbdev@vger.kernel.org, marex@denx.de, dsd@laptop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	airlied@linux.ie, masahiroy@kernel.org,
	Nicolas Pitre <nico@fluxnic.net>,
	Saeed Mahameed <saeedm@mellanox.com>,
	thellstrom@vmware.com, haojian.zhuang@gmail.com,
	geert@linux-m68k.org, linux-renesas-soc@vger.kernel.org,
	Jason Gunthorpe <jgg@ziepe.ca>,
	kieran.bingham+renesas@ideasonboard.com,
	linux-graphics-maintainer@vmware.com,
	Laurent.pinchart@ideasonboard.com, jfrederich@gmail.com,
	robert.jarzmik@free.fr, daniel@zonque.org
Subject: Re: [PATCH 6/8] drm: decouple from CONFIG_FB
Date: Fri, 17 Apr 2020 18:50:41 +0200	[thread overview]
Message-ID: <20200417165041.GA30483@ravnborg.org> (raw)
In-Reply-To: <20200417155553.675905-7-arnd@arndb.de>

Hi Arnd.

On Fri, Apr 17, 2020 at 05:55:51PM +0200, Arnd Bergmann wrote:
> CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
> really should not, to avoid circular dependencies and accidentally
> including potentially dangerous user interfaces in the kernel,
> so change this into a 'depends on' check.
> 
> Two device drivers currently select CONFIG_DRM_KMS_FB_HELPER, but
> as far as I can tell, they do not really need to any more, so those
> selects can be removed.
> 
> This leaves DRM_FBDEV_EMULATION as the only thing that rightfully
> selects CONFIG_DRM_KMS_FB_HELPER, and this now has to depend on
> CONFIG_FB and its dependencies.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/gpu/drm/Kconfig       | 5 +++--
>  drivers/gpu/drm/mxsfb/Kconfig | 1 -
>  drivers/gpu/drm/zte/Kconfig   | 1 -
>  3 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..7c3109133685 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,7 +80,7 @@ config DRM_KMS_HELPER
>  config DRM_KMS_FB_HELPER
>  	bool
>  	depends on DRM_KMS_HELPER
> -	select FB
> +	depends on FB
>  	select FRAMEBUFFER_CONSOLE if !EXPERT
>  	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
>  	select FB_SYS_FOPS
> @@ -111,7 +111,8 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>  
>  config DRM_FBDEV_EMULATION
>  	bool "Enable legacy fbdev support for your modesetting driver"
> -	depends on DRM
> +	depends on DRM && FB
> +	depends on FB=y || DRM=m
>  	select DRM_KMS_HELPER
>  	select DRM_KMS_FB_HELPER
>  	default y
This statement:

	depends on DRM && FB

tell us that both symbols must be either y or m. Any combination of y
and m will do the trick


Then we have this statement:

	depends on FB=y || DRM=m

It tells us that either FB equals y or DRM equals m.

So we have following table

	FB	DRM	Result
	n	n	n
	n	y	n
	n	m	n
	y	n	n
	y	y	y
	y	m	y
	m	n	n
	m	y	N
	m	m	y

So what this try to say is that we cannot have FB a module while DRM is
built-in (marked N in the above).

Could you explain in the changelog why this combination is not good.
(Or tell me if my analysis was flawed).

With this fixed (assuming I am right):
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0dca8f27169e..33916b7b2c50 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -10,7 +10,6 @@ config DRM_MXSFB
>  	depends on COMMON_CLK
>  	select DRM_MXS
>  	select DRM_KMS_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_CMA_HELPER
>  	select DRM_PANEL
>  	help
> diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
> index 90ebaedc11fd..aa8594190b50 100644
> --- a/drivers/gpu/drm/zte/Kconfig
> +++ b/drivers/gpu/drm/zte/Kconfig
> @@ -3,7 +3,6 @@ config DRM_ZTE
>  	tristate "DRM Support for ZTE SoCs"
>  	depends on DRM && ARCH_ZX
>  	select DRM_KMS_CMA_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_HELPER
>  	select SND_SOC_HDMI_CODEC if SND_SOC
>  	select VIDEOMODE_HELPERS
> -- 
> 2.26.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: marex@denx.de, linux-renesas-soc@vger.kernel.org,
	linux-fbdev@vger.kernel.org, dsd@laptop.org,
	Nicolas Pitre <nico@fluxnic.net>,
	airlied@linux.ie, masahiroy@kernel.org, jfrederich@gmail.com,
	Saeed Mahameed <saeedm@mellanox.com>,
	thellstrom@vmware.com, haojian.zhuang@gmail.com,
	Andrzej Hajda <a.hajda@samsung.com>,
	kieran.bingham+renesas@ideasonboard.com, geert@linux-m68k.org,
	dri-devel@lists.freedesktop.org,
	linux-graphics-maintainer@vmware.com, robert.jarzmik@free.fr,
	Jason Gunthorpe <jgg@ziepe.ca>,
	daniel@zonque.org, Laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH 6/8] drm: decouple from CONFIG_FB
Date: Fri, 17 Apr 2020 16:50:41 +0000	[thread overview]
Message-ID: <20200417165041.GA30483@ravnborg.org> (raw)
In-Reply-To: <20200417155553.675905-7-arnd@arndb.de>

Hi Arnd.

On Fri, Apr 17, 2020 at 05:55:51PM +0200, Arnd Bergmann wrote:
> CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
> really should not, to avoid circular dependencies and accidentally
> including potentially dangerous user interfaces in the kernel,
> so change this into a 'depends on' check.
> 
> Two device drivers currently select CONFIG_DRM_KMS_FB_HELPER, but
> as far as I can tell, they do not really need to any more, so those
> selects can be removed.
> 
> This leaves DRM_FBDEV_EMULATION as the only thing that rightfully
> selects CONFIG_DRM_KMS_FB_HELPER, and this now has to depend on
> CONFIG_FB and its dependencies.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/gpu/drm/Kconfig       | 5 +++--
>  drivers/gpu/drm/mxsfb/Kconfig | 1 -
>  drivers/gpu/drm/zte/Kconfig   | 1 -
>  3 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..7c3109133685 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,7 +80,7 @@ config DRM_KMS_HELPER
>  config DRM_KMS_FB_HELPER
>  	bool
>  	depends on DRM_KMS_HELPER
> -	select FB
> +	depends on FB
>  	select FRAMEBUFFER_CONSOLE if !EXPERT
>  	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
>  	select FB_SYS_FOPS
> @@ -111,7 +111,8 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>  
>  config DRM_FBDEV_EMULATION
>  	bool "Enable legacy fbdev support for your modesetting driver"
> -	depends on DRM
> +	depends on DRM && FB
> +	depends on FB=y || DRM=m
>  	select DRM_KMS_HELPER
>  	select DRM_KMS_FB_HELPER
>  	default y
This statement:

	depends on DRM && FB

tell us that both symbols must be either y or m. Any combination of y
and m will do the trick


Then we have this statement:

	depends on FB=y || DRM=m

It tells us that either FB equals y or DRM equals m.

So we have following table

	FB	DRM	Result
	n	n	n
	n	y	n
	n	m	n
	y	n	n
	y	y	y
	y	m	y
	m	n	n
	m	y	N
	m	m	y

So what this try to say is that we cannot have FB a module while DRM is
built-in (marked N in the above).

Could you explain in the changelog why this combination is not good.
(Or tell me if my analysis was flawed).

With this fixed (assuming I am right):
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0dca8f27169e..33916b7b2c50 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -10,7 +10,6 @@ config DRM_MXSFB
>  	depends on COMMON_CLK
>  	select DRM_MXS
>  	select DRM_KMS_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_CMA_HELPER
>  	select DRM_PANEL
>  	help
> diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
> index 90ebaedc11fd..aa8594190b50 100644
> --- a/drivers/gpu/drm/zte/Kconfig
> +++ b/drivers/gpu/drm/zte/Kconfig
> @@ -3,7 +3,6 @@ config DRM_ZTE
>  	tristate "DRM Support for ZTE SoCs"
>  	depends on DRM && ARCH_ZX
>  	select DRM_KMS_CMA_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_HELPER
>  	select SND_SOC_HDMI_CODEC if SND_SOC
>  	select VIDEOMODE_HELPERS
> -- 
> 2.26.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: marex@denx.de, linux-renesas-soc@vger.kernel.org,
	linux-fbdev@vger.kernel.org, dsd@laptop.org,
	Nicolas Pitre <nico@fluxnic.net>,
	airlied@linux.ie, masahiroy@kernel.org, jfrederich@gmail.com,
	Saeed Mahameed <saeedm@mellanox.com>,
	thellstrom@vmware.com, haojian.zhuang@gmail.com,
	Andrzej Hajda <a.hajda@samsung.com>,
	kieran.bingham+renesas@ideasonboard.com, geert@linux-m68k.org,
	dri-devel@lists.freedesktop.org,
	linux-graphics-maintainer@vmware.com, robert.jarzmik@free.fr,
	Jason Gunthorpe <jgg@ziepe.ca>,
	daniel@zonque.org, Laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH 6/8] drm: decouple from CONFIG_FB
Date: Fri, 17 Apr 2020 18:50:41 +0200	[thread overview]
Message-ID: <20200417165041.GA30483@ravnborg.org> (raw)
In-Reply-To: <20200417155553.675905-7-arnd@arndb.de>

Hi Arnd.

On Fri, Apr 17, 2020 at 05:55:51PM +0200, Arnd Bergmann wrote:
> CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
> really should not, to avoid circular dependencies and accidentally
> including potentially dangerous user interfaces in the kernel,
> so change this into a 'depends on' check.
> 
> Two device drivers currently select CONFIG_DRM_KMS_FB_HELPER, but
> as far as I can tell, they do not really need to any more, so those
> selects can be removed.
> 
> This leaves DRM_FBDEV_EMULATION as the only thing that rightfully
> selects CONFIG_DRM_KMS_FB_HELPER, and this now has to depend on
> CONFIG_FB and its dependencies.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/gpu/drm/Kconfig       | 5 +++--
>  drivers/gpu/drm/mxsfb/Kconfig | 1 -
>  drivers/gpu/drm/zte/Kconfig   | 1 -
>  3 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 43594978958e..7c3109133685 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,7 +80,7 @@ config DRM_KMS_HELPER
>  config DRM_KMS_FB_HELPER
>  	bool
>  	depends on DRM_KMS_HELPER
> -	select FB
> +	depends on FB
>  	select FRAMEBUFFER_CONSOLE if !EXPERT
>  	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
>  	select FB_SYS_FOPS
> @@ -111,7 +111,8 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>  
>  config DRM_FBDEV_EMULATION
>  	bool "Enable legacy fbdev support for your modesetting driver"
> -	depends on DRM
> +	depends on DRM && FB
> +	depends on FB=y || DRM=m
>  	select DRM_KMS_HELPER
>  	select DRM_KMS_FB_HELPER
>  	default y
This statement:

	depends on DRM && FB

tell us that both symbols must be either y or m. Any combination of y
and m will do the trick


Then we have this statement:

	depends on FB=y || DRM=m

It tells us that either FB equals y or DRM equals m.

So we have following table

	FB	DRM	Result
	n	n	n
	n	y	n
	n	m	n
	y	n	n
	y	y	y
	y	m	y
	m	n	n
	m	y	N
	m	m	y

So what this try to say is that we cannot have FB a module while DRM is
built-in (marked N in the above).

Could you explain in the changelog why this combination is not good.
(Or tell me if my analysis was flawed).

With this fixed (assuming I am right):
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0dca8f27169e..33916b7b2c50 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -10,7 +10,6 @@ config DRM_MXSFB
>  	depends on COMMON_CLK
>  	select DRM_MXS
>  	select DRM_KMS_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_CMA_HELPER
>  	select DRM_PANEL
>  	help
> diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
> index 90ebaedc11fd..aa8594190b50 100644
> --- a/drivers/gpu/drm/zte/Kconfig
> +++ b/drivers/gpu/drm/zte/Kconfig
> @@ -3,7 +3,6 @@ config DRM_ZTE
>  	tristate "DRM Support for ZTE SoCs"
>  	depends on DRM && ARCH_ZX
>  	select DRM_KMS_CMA_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_HELPER
>  	select SND_SOC_HDMI_CODEC if SND_SOC
>  	select VIDEOMODE_HELPERS
> -- 
> 2.26.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-17 16:50 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 [this message]
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
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=20200417165041.GA30483@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --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=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.