All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Peter Griffin <peter.griffin@linaro.org>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: ohad@wizery.com, devicetree <devicetree@vger.kernel.org>,
	kernel@stlinux.com, vinod.koul@intel.com, lee.jones@linaro.org,
	linux-remoteproc@vger.kernel.org, patrice.chotard@st.com,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	dmaengine@vger.kernel.org, dan.j.williams@intel.com,
	bjorn.andersson@linaro.org,
	"open list:VIRTIO GPU DRIVER"
	<virtualization@lists.linux-foundation.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Date: Tue, 20 Sep 2016 12:33:45 +0300	[thread overview]
Message-ID: <8760pqncee.fsf@intel.com> (raw)
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

WARNING: multiple messages have this Message-ID
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Peter Griffin <peter.griffin@linaro.org>,
	Emil Velikov <emil.l.velikov@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: ohad@wizery.com, devicetree <devicetree@vger.kernel.org>,
	kernel@stlinux.com, vinod.koul@intel.com, lee.jones@linaro.org,
	linux-remoteproc@vger.kernel.org, patrice.chotard@st.com,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux-Kernel\@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	dmaengine@vger.kernel.org, dan.j.williams@intel.com,
	bjorn.andersson@linaro.org,
	"open list\:VIRTIO GPU DRIVER" 
	<virtualization@lists.linux-foundation.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Date: Tue, 20 Sep 2016 12:33:45 +0300	[thread overview]
Message-ID: <8760pqncee.fsf@intel.com> (raw)
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

WARNING: multiple messages have this Message-ID
From: Jani Nikula <jani.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Peter Griffin
	<peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Emil Velikov
	<emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org,
	vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	patrice.chotard-qxv4g6HH51o@public.gmane.org,
	ML dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Linux-Kernel@Vger. Kernel. Org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	"open list:VIRTIO GPU DRIVER"
	<virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	LAKML
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Date: Tue, 20 Sep 2016 12:33:45 +0300	[thread overview]
Message-ID: <8760pqncee.fsf@intel.com> (raw)
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID
From: jani.nikula@linux.intel.com (Jani Nikula)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Date: Tue, 20 Sep 2016 12:33:45 +0300	[thread overview]
Message-ID: <8760pqncee.fsf@intel.com> (raw)
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

  parent reply	other threads:[~2016-09-20  9:33 UTC|newest]

Thread overview: 174+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-05 13:16 [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-13 17:56   ` Bjorn Andersson
2016-09-13 17:56     ` Bjorn Andersson
2016-09-13 17:56     ` Bjorn Andersson
2016-09-14  8:30     ` Lee Jones
2016-09-14  8:30     ` Lee Jones
2016-09-14  8:30       ` Lee Jones
2016-09-14  8:30       ` Lee Jones
2016-09-05 13:16 ` [PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 11:59   ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59   ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in " Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader " Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-19 23:18   ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-20  8:32     ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  9:33       ` Jani Nikula
2016-09-20  9:33       ` Jani Nikula [this message]
2016-09-20  9:33         ` Jani Nikula
2016-09-20  9:33         ` Jani Nikula
2016-09-20  9:33         ` Jani Nikula
2016-10-06  9:37         ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06 10:45           ` Emil Velikov
2016-10-06 10:45           ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-07 17:44             ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-09-21 12:09       ` Emil Velikov
2016-09-21 12:09       ` Emil Velikov
2016-09-21 12:09         ` Emil Velikov
2016-09-21 12:09         ` Emil Velikov
2016-09-27 17:01         ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-10-06 10:10           ` Emil Velikov
2016-10-06 10:10           ` Emil Velikov
2016-10-06 10:10             ` Emil Velikov
2016-10-06 10:10             ` Emil Velikov
2016-10-06 10:48         ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 11:31           ` Emil Velikov
2016-10-06 11:31             ` Emil Velikov
2016-10-06 11:31             ` Emil Velikov
2016-10-06 11:31           ` Emil Velikov
2016-09-05 13:17 ` [PATCH v9 18/19] drm/virtio: kconfig: Fixup white space Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17 ` Peter Griffin
2016-09-05 13:17 ` [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n' Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17 ` Peter Griffin
2016-09-13  9:31 ` [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
2016-09-13  9:31 ` Peter Griffin
2016-09-13  9:31   ` Peter Griffin
2016-09-13  9:31   ` Peter Griffin
2016-09-13 18:06   ` Bjorn Andersson
2016-09-13 18:06   ` Bjorn Andersson
2016-09-13 18:06     ` Bjorn Andersson
2016-09-13 18:06     ` Bjorn Andersson
2016-09-14  6:59     ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59     ` Patrice Chotard
2016-09-14 13:07     ` Vinod Koul
2016-09-14 13:07       ` Vinod Koul
2016-09-14 13:07       ` Vinod Koul
2016-09-15 16:20       ` Vinod Koul
2016-09-15 16:20       ` Vinod Koul
2016-09-15 16:20         ` Vinod Koul
2016-09-15 16:20         ` Vinod Koul
2016-09-14 13:07     ` Vinod Koul
2016-09-19  9:34 [PATCH 0/2] Fix recursive Kconfig depedency issue Peter Griffin
2016-09-19  9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-20  7:20   ` [PATCH v9 17/19] " Emil Velikov
2016-09-20  7:24     ` Emil Velikov

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=8760pqncee.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=kernel@stlinux.com \
    --cc=kraxel@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=patrice.chotard@st.com \
    --cc=peter.griffin@linaro.org \
    --cc=vinod.koul@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.