From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Heiko Stuebner <heiko@sntech.de>, Andi Shyti <andi@etezian.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table
Date: Tue, 14 Mar 2023 07:44:04 +0100 [thread overview]
Message-ID: <ed293caf-e787-a29e-f1c5-bdcaf1aa483a@linaro.org> (raw)
In-Reply-To: <9bf3dd37-71c2-4118-a8da-40e656b42d10@sirena.org.uk>
On 13/03/2023 20:22, Mark Brown wrote:
> On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote:
>> On 13/03/2023 14:55, Mark Brown wrote:
>>> On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote:
>
>>>> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=]
>
>>> It would be much better to fix of_match_ptr() and/or the module stuff
>>> that also references the match table here.
>
>> Why? The recommendation is in general not to use of_match_ptr, because
>> there are little benefits but it disables matching via PRP0001. Jonathan
>> in parallel thread explicitly said of_match_ptr should disappear and he
>> is not accepting any new code with it. And in general he is right.
>
> If that's the case then why are you adding maybe unused annotations for
> half the drivers rather than removing their of_match_ptr() usages?
> There doesn't seem to be any logic here, it's just randomly making
> changes as far as I can tell.
These are not random but depend on whether OF is the only matching
method or one of few. Although for IIO all of my patches would be
dropping the of_match_ptr... For some cases in other patchsets I added
__maybe_unused also because of_match_node(), when the table is not used
in driver of_match_table.
>
> The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to
> do the right thing for CONFIG_ACPI.
That's actually interesting idea, kind of obvious so I wonder why it
wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus:
Respect PRP0001 when retrieving device match data"). Maybe not to
populate OF device ID tables for the ACPI systems which do not care
about PRP0001?
> It doesn't buy us huge amounts but
> it also costs us very little and may be useful in future. When there's
> missing annotations it's not causing issues for practical configurations
> as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd
> be even less of an issue.
Best regards,
Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Heiko Stuebner <heiko@sntech.de>, Andi Shyti <andi@etezian.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table
Date: Tue, 14 Mar 2023 07:44:04 +0100 [thread overview]
Message-ID: <ed293caf-e787-a29e-f1c5-bdcaf1aa483a@linaro.org> (raw)
In-Reply-To: <9bf3dd37-71c2-4118-a8da-40e656b42d10@sirena.org.uk>
On 13/03/2023 20:22, Mark Brown wrote:
> On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote:
>> On 13/03/2023 14:55, Mark Brown wrote:
>>> On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote:
>
>>>> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=]
>
>>> It would be much better to fix of_match_ptr() and/or the module stuff
>>> that also references the match table here.
>
>> Why? The recommendation is in general not to use of_match_ptr, because
>> there are little benefits but it disables matching via PRP0001. Jonathan
>> in parallel thread explicitly said of_match_ptr should disappear and he
>> is not accepting any new code with it. And in general he is right.
>
> If that's the case then why are you adding maybe unused annotations for
> half the drivers rather than removing their of_match_ptr() usages?
> There doesn't seem to be any logic here, it's just randomly making
> changes as far as I can tell.
These are not random but depend on whether OF is the only matching
method or one of few. Although for IIO all of my patches would be
dropping the of_match_ptr... For some cases in other patchsets I added
__maybe_unused also because of_match_node(), when the table is not used
in driver of_match_table.
>
> The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to
> do the right thing for CONFIG_ACPI.
That's actually interesting idea, kind of obvious so I wonder why it
wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus:
Respect PRP0001 when retrieving device match data"). Maybe not to
populate OF device ID tables for the ACPI systems which do not care
about PRP0001?
> It doesn't buy us huge amounts but
> it also costs us very little and may be useful in future. When there's
> missing annotations it's not causing issues for practical configurations
> as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd
> be even less of an issue.
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Heiko Stuebner <heiko@sntech.de>, Andi Shyti <andi@etezian.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table
Date: Tue, 14 Mar 2023 07:44:04 +0100 [thread overview]
Message-ID: <ed293caf-e787-a29e-f1c5-bdcaf1aa483a@linaro.org> (raw)
In-Reply-To: <9bf3dd37-71c2-4118-a8da-40e656b42d10@sirena.org.uk>
On 13/03/2023 20:22, Mark Brown wrote:
> On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote:
>> On 13/03/2023 14:55, Mark Brown wrote:
>>> On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote:
>
>>>> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=]
>
>>> It would be much better to fix of_match_ptr() and/or the module stuff
>>> that also references the match table here.
>
>> Why? The recommendation is in general not to use of_match_ptr, because
>> there are little benefits but it disables matching via PRP0001. Jonathan
>> in parallel thread explicitly said of_match_ptr should disappear and he
>> is not accepting any new code with it. And in general he is right.
>
> If that's the case then why are you adding maybe unused annotations for
> half the drivers rather than removing their of_match_ptr() usages?
> There doesn't seem to be any logic here, it's just randomly making
> changes as far as I can tell.
These are not random but depend on whether OF is the only matching
method or one of few. Although for IIO all of my patches would be
dropping the of_match_ptr... For some cases in other patchsets I added
__maybe_unused also because of_match_node(), when the table is not used
in driver of_match_table.
>
> The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to
> do the right thing for CONFIG_ACPI.
That's actually interesting idea, kind of obvious so I wonder why it
wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus:
Respect PRP0001 when retrieving device match data"). Maybe not to
populate OF device ID tables for the ACPI systems which do not care
about PRP0001?
> It doesn't buy us huge amounts but
> it also costs us very little and may be useful in future. When there's
> missing annotations it's not causing issues for practical configurations
> as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd
> be even less of an issue.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
Heiko Stuebner <heiko@sntech.de>, Andi Shyti <andi@etezian.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Stephen Boyd <sboyd@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table
Date: Tue, 14 Mar 2023 07:44:04 +0100 [thread overview]
Message-ID: <ed293caf-e787-a29e-f1c5-bdcaf1aa483a@linaro.org> (raw)
In-Reply-To: <9bf3dd37-71c2-4118-a8da-40e656b42d10@sirena.org.uk>
On 13/03/2023 20:22, Mark Brown wrote:
> On Mon, Mar 13, 2023 at 07:39:45PM +0100, Krzysztof Kozlowski wrote:
>> On 13/03/2023 14:55, Mark Brown wrote:
>>> On Fri, Mar 10, 2023 at 11:28:42PM +0100, Krzysztof Kozlowski wrote:
>
>>>> drivers/spi/spi-armada-3700.c:807:34: error: ‘a3700_spi_dt_ids’ defined but not used [-Werror=unused-const-variable=]
>
>>> It would be much better to fix of_match_ptr() and/or the module stuff
>>> that also references the match table here.
>
>> Why? The recommendation is in general not to use of_match_ptr, because
>> there are little benefits but it disables matching via PRP0001. Jonathan
>> in parallel thread explicitly said of_match_ptr should disappear and he
>> is not accepting any new code with it. And in general he is right.
>
> If that's the case then why are you adding maybe unused annotations for
> half the drivers rather than removing their of_match_ptr() usages?
> There doesn't seem to be any logic here, it's just randomly making
> changes as far as I can tell.
These are not random but depend on whether OF is the only matching
method or one of few. Although for IIO all of my patches would be
dropping the of_match_ptr... For some cases in other patchsets I added
__maybe_unused also because of_match_node(), when the table is not used
in driver of_match_table.
>
> The PRP0001 stuff isn't an issue, of_match_ptr() can just be changed to
> do the right thing for CONFIG_ACPI.
That's actually interesting idea, kind of obvious so I wonder why it
wasn't done like this in the first place in 886ca88be6b3 ("ACPI / bus:
Respect PRP0001 when retrieving device match data"). Maybe not to
populate OF device ID tables for the ACPI systems which do not care
about PRP0001?
> It doesn't buy us huge amounts but
> it also costs us very little and may be useful in future. When there's
> missing annotations it's not causing issues for practical configurations
> as far as I can tell, and if the macro were updated for CONFIG_ACPI it'd
> be even less of an issue.
Best regards,
Krzysztof
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2023-03-14 6:44 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 22:28 [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 02/16] spi: mtk-pmif: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-13 8:46 ` AngeloGioacchino Del Regno
2023-03-13 8:46 ` AngeloGioacchino Del Regno
2023-03-13 8:46 ` AngeloGioacchino Del Regno
2023-03-13 8:46 ` AngeloGioacchino Del Regno
2023-03-29 4:15 ` Stephen Boyd
2023-03-29 4:15 ` Stephen Boyd
2023-03-29 4:15 ` Stephen Boyd
2023-03-29 4:15 ` Stephen Boyd
2023-03-29 4:17 ` Stephen Boyd
2023-03-29 4:17 ` Stephen Boyd
2023-03-29 4:17 ` Stephen Boyd
2023-03-29 4:17 ` Stephen Boyd
2023-03-29 7:13 ` Krzysztof Kozlowski
2023-03-29 7:13 ` Krzysztof Kozlowski
2023-03-29 7:13 ` Krzysztof Kozlowski
2023-03-29 7:13 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 03/16] spi: meson-spicc: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-11 21:02 ` Martin Blumenstingl
2023-03-11 21:02 ` Martin Blumenstingl
2023-03-11 21:02 ` Martin Blumenstingl
2023-03-11 21:02 ` Martin Blumenstingl
2023-03-10 22:28 ` [PATCH 04/16] spi: meson-spifc: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-11 21:03 ` Martin Blumenstingl
2023-03-11 21:03 ` Martin Blumenstingl
2023-03-11 21:03 ` Martin Blumenstingl
2023-03-11 21:03 ` Martin Blumenstingl
2023-03-10 22:28 ` [PATCH 05/16] spi: orion: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 06/16] spi: rockchip: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-11 12:56 ` Heiko Stuebner
2023-03-11 12:56 ` Heiko Stuebner
2023-03-11 12:56 ` Heiko Stuebner
2023-03-11 12:56 ` Heiko Stuebner
2023-03-10 22:28 ` [PATCH 07/16] spi: s3c64xx: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-11 11:45 ` Andi Shyti
2023-03-11 11:45 ` Andi Shyti
2023-03-11 11:45 ` Andi Shyti
2023-03-11 11:45 ` Andi Shyti
2023-03-10 22:28 ` [PATCH 08/16] spi: img-spfi: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 09/16] spi: pic32-sqi: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 10/16] spi: pic32: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 11/16] spi: st-ssc4: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 12/16] spi: pxa2xx: Mark OF related data as maybe unused Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 13/16] spi: bcm-qspi: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:36 ` Florian Fainelli
2023-03-10 22:36 ` Florian Fainelli
2023-03-10 22:36 ` Florian Fainelli
2023-03-10 22:36 ` Florian Fainelli
2023-03-10 22:28 ` [PATCH 14/16] spi: sh-msiof: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 15/16] spi: sc18is602: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` [PATCH 16/16] spi: rspi: " Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-10 22:28 ` Krzysztof Kozlowski
2023-03-13 13:55 ` [PATCH 01/16] spi: armada-3700: Drop of_match_ptr for ID table Mark Brown
2023-03-13 13:55 ` Mark Brown
2023-03-13 13:55 ` Mark Brown
2023-03-13 13:55 ` Mark Brown
2023-03-13 18:39 ` Krzysztof Kozlowski
2023-03-13 18:39 ` Krzysztof Kozlowski
2023-03-13 18:39 ` Krzysztof Kozlowski
2023-03-13 18:39 ` Krzysztof Kozlowski
2023-03-13 19:22 ` Mark Brown
2023-03-13 19:22 ` Mark Brown
2023-03-13 19:22 ` Mark Brown
2023-03-13 19:22 ` Mark Brown
2023-03-14 6:44 ` Krzysztof Kozlowski [this message]
2023-03-14 6:44 ` Krzysztof Kozlowski
2023-03-14 6:44 ` Krzysztof Kozlowski
2023-03-14 6:44 ` Krzysztof Kozlowski
2023-03-14 13:26 ` Mark Brown
2023-03-14 13:26 ` Mark Brown
2023-03-14 13:26 ` Mark Brown
2023-03-14 13:26 ` Mark Brown
2023-03-13 18:20 ` (subset) " Mark Brown
2023-03-13 18:20 ` Mark Brown
2023-03-13 18:20 ` Mark Brown
2023-03-13 18:20 ` Mark Brown
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=ed293caf-e787-a29e-f1c5-bdcaf1aa483a@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andi@etezian.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=broonie@kernel.org \
--cc=daniel@zonque.org \
--cc=haojian.zhuang@gmail.com \
--cc=heiko@sntech.de \
--cc=jbrunet@baylibre.com \
--cc=kdasu.kdev@gmail.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=matthias.bgg@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=robert.jarzmik@free.fr \
--cc=sboyd@kernel.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.