| Message ID | YzIzUjUuJKf0mkKg@work (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [next] ASoC: uapi: Replace zero-length arrays with __DECLARE_FLEX_ARRAY() helper | expand |
On Mon, Sep 26, 2022 at 06:18:42PM -0500, Gustavo A. R. Silva wrote: > Zero-length arrays are deprecated and we are moving towards adopting > C99 flexible-array members, instead. So, replace zero-length arrays > declarations in anonymous union with the new __DECLARE_FLEX_ARRAY() > helper macro. > > This helper allows for flexible-array members in unions. > > Link: https://github.com/KSPP/linux/issues/193 > Link: https://github.com/KSPP/linux/issues/227 > Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Some day after the __element_count__ attribute exists, we might want to consider a __type_select__ attribute to tie union members to a variable outside the union (like the "type" member here). Reviewed-by: Kees Cook <keescook@chromium.org>
On 9/27/2022 1:18 AM, Gustavo A. R. Silva wrote: > Zero-length arrays are deprecated and we are moving towards adopting > C99 flexible-array members, instead. So, replace zero-length arrays > declarations in anonymous union with the new __DECLARE_FLEX_ARRAY() > helper macro. > > This helper allows for flexible-array members in unions. > > Link: https://github.com/KSPP/linux/issues/193 > Link: https://github.com/KSPP/linux/issues/227 > Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > include/uapi/sound/asoc.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h > index 053949287ce8..dd8ad790fc15 100644 > --- a/include/uapi/sound/asoc.h > +++ b/include/uapi/sound/asoc.h > @@ -226,9 +226,9 @@ struct snd_soc_tplg_vendor_array { > __le32 type; /* SND_SOC_TPLG_TUPLE_TYPE_ */ > __le32 num_elems; /* number of elements in array */ > union { > - struct snd_soc_tplg_vendor_uuid_elem uuid[0]; > - struct snd_soc_tplg_vendor_value_elem value[0]; > - struct snd_soc_tplg_vendor_string_elem string[0]; > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid); > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value); > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string); > }; > } __attribute__((packed)); > Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Hi Takashi, I wonder if this can go through your tree. It's already been reviewed by a couple of people. :) Thanks -- Gustavo On 9/26/22 18:18, Gustavo A. R. Silva wrote: > Zero-length arrays are deprecated and we are moving towards adopting > C99 flexible-array members, instead. So, replace zero-length arrays > declarations in anonymous union with the new __DECLARE_FLEX_ARRAY() > helper macro. > > This helper allows for flexible-array members in unions. > > Link: https://github.com/KSPP/linux/issues/193 > Link: https://github.com/KSPP/linux/issues/227 > Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> > --- > include/uapi/sound/asoc.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h > index 053949287ce8..dd8ad790fc15 100644 > --- a/include/uapi/sound/asoc.h > +++ b/include/uapi/sound/asoc.h > @@ -226,9 +226,9 @@ struct snd_soc_tplg_vendor_array { > __le32 type; /* SND_SOC_TPLG_TUPLE_TYPE_ */ > __le32 num_elems; /* number of elements in array */ > union { > - struct snd_soc_tplg_vendor_uuid_elem uuid[0]; > - struct snd_soc_tplg_vendor_value_elem value[0]; > - struct snd_soc_tplg_vendor_string_elem string[0]; > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid); > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value); > + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string); > }; > } __attribute__((packed)); >
On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote: > Hi Takashi, > > I wonder if this can go through your tree. > > It's already been reviewed by a couple of people. :) As documented in submitting-patches.rst please send patches to the maintainers for the code you would like to change. The normal kernel workflow is that people apply patches from their inboxes, if they aren't copied they are likely to not see the patch at all and it is much more difficult to apply patches.
On 2/2/23 15:09, Mark Brown wrote: > On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote: >> Hi Takashi, >> >> I wonder if this can go through your tree. >> >> It's already been reviewed by a couple of people. :) > > As documented in submitting-patches.rst please send patches to the > maintainers for the code you would like to change. The normal kernel > workflow is that people apply patches from their inboxes, if they aren't > copied they are likely to not see the patch at all and it is much more > difficult to apply patches. Yep; that's exactly what I did. :) scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND) Takashi Iwai <tiwai@suse.com> (maintainer:SOUND) alsa-devel@alsa-project.org (moderated list:SOUND) linux-kernel@vger.kernel.org (open list) If you're one the maintainers of that file, you're clearly not listed as such. -- Gustavo
On Thu, Feb 02, 2023 at 03:18:47PM -0600, Gustavo A. R. Silva wrote: > On 2/2/23 15:09, Mark Brown wrote: > > On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote: > > As documented in submitting-patches.rst please send patches to the > > maintainers for the code you would like to change. The normal kernel > > workflow is that people apply patches from their inboxes, if they aren't > > copied they are likely to not see the patch at all and it is much more > > difficult to apply patches. > Yep; that's exactly what I did. :) > scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h > Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND) > Takashi Iwai <tiwai@suse.com> (maintainer:SOUND) > alsa-devel@alsa-project.org (moderated list:SOUND) > linux-kernel@vger.kernel.org (open list) > If you're one the maintainers of that file, you're clearly not listed as such. You did manage to figure out that it's an ASoC patch given the subject line...
On 2/3/23 06:57, Mark Brown wrote: > On Thu, Feb 02, 2023 at 03:18:47PM -0600, Gustavo A. R. Silva wrote: >> On 2/2/23 15:09, Mark Brown wrote: >>> On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote: > >>> As documented in submitting-patches.rst please send patches to the >>> maintainers for the code you would like to change. The normal kernel >>> workflow is that people apply patches from their inboxes, if they aren't >>> copied they are likely to not see the patch at all and it is much more >>> difficult to apply patches. > >> Yep; that's exactly what I did. :) > >> scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h >> Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND) >> Takashi Iwai <tiwai@suse.com> (maintainer:SOUND) >> alsa-devel@alsa-project.org (moderated list:SOUND) >> linux-kernel@vger.kernel.org (open list) > >> If you're one the maintainers of that file, you're clearly not listed as such. > > You did manage to figure out that it's an ASoC patch given the subject > line... As with the list of maintainers, I use a tool to get that info: git log --oneline include/uapi/sound/asoc.h I think we have run into this same issue (you not being listed in the MAINTAINERS file) at least once in the past, right? (thinkingface) IMHO, the sensible solution for this is to keep the MAINTAINERS file up-to-date. So, get_maintainer.pl can continue to be useful for people. -- Gustavo
On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote: > I think we have run into this same issue (you not being listed in the > MAINTAINERS file) at least once in the past, right? (thinkingface) > IMHO, the sensible solution for this is to keep the MAINTAINERS file > up-to-date. So, get_maintainer.pl can continue to be useful for people. Sure, feel free to send an update...
On 2/3/23 07:45, Mark Brown wrote: > On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote: > >> I think we have run into this same issue (you not being listed in the >> MAINTAINERS file) at least once in the past, right? (thinkingface) > >> IMHO, the sensible solution for this is to keep the MAINTAINERS file >> up-to-date. So, get_maintainer.pl can continue to be useful for people. > > Sure, feel free to send an update... [chuckles]
On Fri, Feb 03, 2023 at 01:45:02PM +0000, Mark Brown wrote: > On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote: > > > I think we have run into this same issue (you not being listed in the > > MAINTAINERS file) at least once in the past, right? (thinkingface) > > > IMHO, the sensible solution for this is to keep the MAINTAINERS file > > up-to-date. So, get_maintainer.pl can continue to be useful for people. > > Sure, feel free to send an update... Is this accurate? diff --git a/MAINTAINERS b/MAINTAINERS index 7f86d02cb427..e21a3412a546 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19564,6 +19564,8 @@ F: Documentation/devicetree/bindings/sound/ F: Documentation/sound/soc/ F: include/dt-bindings/sound/ F: include/sound/soc* +F: include/sound/sof/ +F: include/uapi/sound/asoc.h F: sound/soc/ SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS
On Fri, Feb 03, 2023 at 04:29:41PM +0000, Kees Cook wrote: > On Fri, Feb 03, 2023 at 01:45:02PM +0000, Mark Brown wrote: > > Sure, feel free to send an update... > Is this accurate? > diff --git a/MAINTAINERS b/MAINTAINERS > index 7f86d02cb427..e21a3412a546 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19564,6 +19564,8 @@ F: Documentation/devicetree/bindings/sound/ > F: Documentation/sound/soc/ > F: include/dt-bindings/sound/ > F: include/sound/soc* > +F: include/sound/sof/ > +F: include/uapi/sound/asoc.h > F: sound/soc/ Might be missing stuff but those are both good additions. Looks like the SOF directory also wants adding to the SOF section in MAINTAINERS.
diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h index 053949287ce8..dd8ad790fc15 100644 --- a/include/uapi/sound/asoc.h +++ b/include/uapi/sound/asoc.h @@ -226,9 +226,9 @@ struct snd_soc_tplg_vendor_array { __le32 type; /* SND_SOC_TPLG_TUPLE_TYPE_ */ __le32 num_elems; /* number of elements in array */ union { - struct snd_soc_tplg_vendor_uuid_elem uuid[0]; - struct snd_soc_tplg_vendor_value_elem value[0]; - struct snd_soc_tplg_vendor_string_elem string[0]; + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid); + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value); + __DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string); }; } __attribute__((packed));
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new __DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/227 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> --- include/uapi/sound/asoc.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)