* Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
[not found] <af2d45578f7cdf908eb83cad3371b41315b7b5c4.camel@linux.intel.com>
@ 2019-07-30 16:16 ` Pierre-Louis Bossart
2019-07-30 18:11 ` Liam Girdwood
0 siblings, 1 reply; 5+ messages in thread
From: Pierre-Louis Bossart @ 2019-07-30 16:16 UTC (permalink / raw)
To: Liam Girdwood, linux-firmware; +Cc: alsa-devel, SOF
[fixed alsa-devel email]
On 7/30/19 10:33 AM, Liam Girdwood wrote:
> The following changes since commit dff98c6c57383fe343407bcb7b6e775e0b87274f:
>
> Merge branch 'master' of git://github.com/skeggsb/linux-firmware (2019-07-26 07:32:37 -0400)
>
> are available in the Git repository at:
>
> https://github.com/thesofproject/linux-firmware.git sof-v1.3
>
> for you to fetch changes up to cde3a116cea96976125b9215b303edfda85c9b54:
>
> sof: Add Intel SOF V1.3 release firmware binaries. (2019-07-30 16:06:41 +0100)
>
> ----------------------------------------------------------------
> Liam Girdwood (1):
> sof: Add Intel SOF V1.3 release firmware binaries.
>
> LICENCE.sof | 1090 ++++++++++++++++++++++++++
Humm, that LICENSE file needs to be double-checked. Is there any reason
why the text of this LICENSE.sof is different the usual text, e.g. from
the LICENSE.adsp_sst?
You are missing both the first part:
***** INTEL BINARY FIRMWARE RELEASE LICENCE ********************************
Copyright (c) 2014-15 Intel Corporation.
All rights reserved.
Redistribution.
Redistribution and use in binary form, without modification, are permitted
provided that the following conditions are met:
* Redistributions must reproduce the above copyright notice and the
following disclaimer in the documentation and/or other materials
provided
with the distribution.
* Neither the name of Intel Corporation nor the names of its
suppliers may
be used to endorse or promote products derived from this software
without
specific prior written permission.
* No reverse engineering, decompilation, or disassembly of this
software is
permitted.
and the DISCLAIMER part, both of which seem pretty important to me.
IANAL, but seeing only a patent clause looks odd. There should be a
mention of redistribution and a clear disclaimer (not sure about the
reverse engineering parts since the code is available it makes no sense).
> WHENCE | 33 +
> intel/sof/apl/intel/sof-apl-v1.3.ri | Bin 0 -> 270336 bytes
> intel/sof/bdw/sof-bdw-v1.3.ri | Bin 0 -> 100144 bytes
> intel/sof/byt/sof-byt-v1.3.ri | Bin 0 -> 89668 bytes
> intel/sof/cht/sof-cht-v1.3.ri | Bin 0 -> 90484 bytes
> intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri | Bin 0 -> 274432 bytes
> intel/sof/icl/intel/sof-icl-v1.3.ri | Bin 0 -> 278528 bytes
There are two types of platforms, the ones which require the Intel
firmware to be signed with a private production key and the ones that
are signed with the SOF community key.
if we have a single directory, then how do we deal with the two cases?
It's not even clear to me which of the two cases are handled here.
> intel/sof/sof-apl.ri | 1 +
> intel/sof/sof-bdw.ri | 1 +
> intel/sof/sof-byt.ri | 1 +
> intel/sof/sof-cht.ri | 1 +
> intel/sof/sof-cml.ri | 1 +
> intel/sof/sof-cnl.ri | 1 +
> intel/sof/sof-glk.ri | 1 +
> intel/sof/sof-icl.ri | 1 +
> intel/sof/sof-whl.ri | 1 +
unless I am missing something, we don't have any tables in the Linux
kernel for the WHL and CML configurations, and IIRC we only generate
sof-cnl.ri. Is there actually a user for sof-whl.ri and sof-cml.ri?
> 17 files changed, 1132 insertions(+)
> create mode 100644 LICENCE.sof
> create mode 100644 intel/sof/apl/intel/sof-apl-v1.3.ri
> create mode 100644 intel/sof/bdw/sof-bdw-v1.3.ri
> create mode 100644 intel/sof/byt/sof-byt-v1.3.ri
> create mode 100644 intel/sof/cht/sof-cht-v1.3.ri
> create mode 100644 intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri
> create mode 100644 intel/sof/icl/intel/sof-icl-v1.3.ri
> create mode 120000 intel/sof/sof-apl.ri
> create mode 120000 intel/sof/sof-bdw.ri
> create mode 120000 intel/sof/sof-byt.ri
> create mode 120000 intel/sof/sof-cht.ri
> create mode 120000 intel/sof/sof-cml.ri
> create mode 120000 intel/sof/sof-cnl.ri
> create mode 120000 intel/sof/sof-glk.ri
> create mode 120000 intel/sof/sof-icl.ri
> create mode 120000 intel/sof/sof-whl.ri
>
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
2019-07-30 16:16 ` [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries Pierre-Louis Bossart
@ 2019-07-30 18:11 ` Liam Girdwood
2019-07-30 21:09 ` Pierre-Louis Bossart
0 siblings, 1 reply; 5+ messages in thread
From: Liam Girdwood @ 2019-07-30 18:11 UTC (permalink / raw)
To: Pierre-Louis Bossart, linux-firmware; +Cc: alsa-devel, SOF
On Tue, 2019-07-30 at 11:16 -0500, Pierre-Louis Bossart wrote:
> [fixed alsa-devel email]
Thanks, auto-complete with my butter fingers....
>
> On 7/30/19 10:33 AM, Liam Girdwood wrote:
> > The following changes since commit
> > dff98c6c57383fe343407bcb7b6e775e0b87274f:
> >
> > Merge branch 'master' of git://github.com/skeggsb/linux-firmware
> > (2019-07-26 07:32:37 -0400)
> >
> > are available in the Git repository at:
> >
> > https://github.com/thesofproject/linux-firmware.git sof-v1.3
> >
> > for you to fetch changes up to
> > cde3a116cea96976125b9215b303edfda85c9b54:
> >
> > sof: Add Intel SOF V1.3 release firmware binaries. (2019-07-30
> > 16:06:41 +0100)
> >
> > ----------------------------------------------------------------
> > Liam Girdwood (1):
> > sof: Add Intel SOF V1.3 release firmware binaries.
> >
> > LICENCE.sof | 1090
> > ++++++++++++++++++++++++++
>
> Humm, that LICENSE file needs to be double-checked. Is there any
> reason
> why the text of this LICENSE.sof is different the usual text, e.g.
> from
> the LICENSE.adsp_sst?
LICENCE.adsp_sst is for the closed source firmware and LICENCE.sof is
for SOF. The key difference is the removal of Intel binary FW licence
and addition of BSD 3c, MIT, ISC and BSD 2c from SOF LICENCE file. Both
files are the same wrt newlib.
>
> You are missing both the first part:
>
> ***** INTEL BINARY FIRMWARE RELEASE LICENCE
> ********************************
>
> Copyright (c) 2014-15 Intel Corporation.
> All rights reserved.
>
> Redistribution.
>
> Redistribution and use in binary form, without modification, are
> permitted
> provided that the following conditions are met:
> * Redistributions must reproduce the above copyright notice and
> the
> following disclaimer in the documentation and/or other
> materials
> provided
> with the distribution.
> * Neither the name of Intel Corporation nor the names of its
> suppliers may
> be used to endorse or promote products derived from this
> software
> without
> specific prior written permission.
These two are in the BSD 3 clause licence (which is included).
> * No reverse engineering, decompilation, or disassembly of this
> software is
> permitted.
I'm not following why we need the reverse engineering conditions for
opensource binaries.
>
> and the DISCLAIMER part, both of which seem pretty important to me.
Disclaimer is in BSD 3 clause and MIT licence - exact same as the
sources.
>
> IANAL, but seeing only a patent clause looks odd. There should be a
> mention of redistribution and a clear disclaimer (not sure about the
> reverse engineering parts since the code is available it makes no
> sense).
Patent clause is exactly the same as SST FW.
>
> > WHENCE | 33 +
> > intel/sof/apl/intel/sof-apl-v1.3.ri | Bin 0 -> 270336
> > bytes
> > intel/sof/bdw/sof-bdw-v1.3.ri | Bin 0 -> 100144
> > bytes
> > intel/sof/byt/sof-byt-v1.3.ri | Bin 0 -> 89668
> > bytes
> > intel/sof/cht/sof-cht-v1.3.ri | Bin 0 -> 90484
> > bytes
> > intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri | Bin 0 -> 274432
> > bytes
> > intel/sof/icl/intel/sof-icl-v1.3.ri | Bin 0 -> 278528
> > bytes
>
> There are two types of platforms, the ones which require the Intel
> firmware to be signed with a private production key and the ones
> that
> are signed with the SOF community key.
>
> if we have a single directory, then how do we deal with the two
> cases?
I've not yet upstreamed the community signed versions yet so everything
is in the intel/sof/platform/key/ directory structure.
> It's not even clear to me which of the two cases are handled here.
>
Intel signed binaries, since they are in intel/sof/platform/intel
directory. Community signed will go in intel/sof/platform/community/
dir.
> > intel/sof/sof-apl.ri | 1 +
> > intel/sof/sof-bdw.ri | 1 +
> > intel/sof/sof-byt.ri | 1 +
> > intel/sof/sof-cht.ri | 1 +
> > intel/sof/sof-cml.ri | 1 +
> > intel/sof/sof-cnl.ri | 1 +
> > intel/sof/sof-glk.ri | 1 +
> > intel/sof/sof-icl.ri | 1 +
> > intel/sof/sof-whl.ri | 1 +
>
> unless I am missing something, we don't have any tables in the Linux
> kernel for the WHL and CML configurations, and IIRC we only generate
> sof-cnl.ri. Is there actually a user for sof-whl.ri and sof-cml.ri?
>
There are glk users hence the addition of whl and cml.
Liam
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
2019-07-30 18:11 ` Liam Girdwood
@ 2019-07-30 21:09 ` Pierre-Louis Bossart
2019-07-30 21:19 ` Josh Boyer
0 siblings, 1 reply; 5+ messages in thread
From: Pierre-Louis Bossart @ 2019-07-30 21:09 UTC (permalink / raw)
To: Liam Girdwood, linux-firmware; +Cc: alsa-devel, SOF
>>> ----------------------------------------------------------------
>>> Liam Girdwood (1):
>>> sof: Add Intel SOF V1.3 release firmware binaries.
>>>
>>> LICENCE.sof | 1090
>>> ++++++++++++++++++++++++++
>>
>> Humm, that LICENSE file needs to be double-checked. Is there any
>> reason
>> why the text of this LICENSE.sof is different the usual text, e.g.
>> from
>> the LICENSE.adsp_sst?
>
> LICENCE.adsp_sst is for the closed source firmware and LICENCE.sof is
> for SOF. The key difference is the removal of Intel binary FW licence
> and addition of BSD 3c, MIT, ISC and BSD 2c from SOF LICENCE file. Both
> files are the same wrt newlib.
I would kindly ask that you run this by legal.
The BSD license is provided for the source files, it's a stretch to say
that the license extends to binaries without a statement that says that
the binary firmware is only made of those source files, unmodified and
without proprietary extensions. And to the best of my knowledge the
newlib dependencies do not apply when compiling with XCC.
>> * No reverse engineering, decompilation, or disassembly of this
>> software is
>> permitted.
>
> I'm not following why we need the reverse engineering conditions for
> opensource binaries.
me neither, that's why I stated that the model has to be different from SST.
>> and the DISCLAIMER part, both of which seem pretty important to me.
>
> Disclaimer is in BSD 3 clause and MIT licence - exact same as the
> sources.
Maybe I am splitting hair, but I'd like a professional opinion on that
license file. Better safe than sorry. I had GKH tell me on Friday to fix
a (c) 2017-19 and use (c) 2017-2019...
>>
>> IANAL, but seeing only a patent clause looks odd. There should be a
>> mention of redistribution and a clear disclaimer (not sure about the
>> reverse engineering parts since the code is available it makes no
>> sense).
>
> Patent clause is exactly the same as SST FW.
>
>>
>>> WHENCE | 33 +
>>> intel/sof/apl/intel/sof-apl-v1.3.ri | Bin 0 -> 270336
>>> bytes
>>> intel/sof/bdw/sof-bdw-v1.3.ri | Bin 0 -> 100144
>>> bytes
>>> intel/sof/byt/sof-byt-v1.3.ri | Bin 0 -> 89668
>>> bytes
>>> intel/sof/cht/sof-cht-v1.3.ri | Bin 0 -> 90484
>>> bytes
>>> intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri | Bin 0 -> 274432
>>> bytes
>>> intel/sof/icl/intel/sof-icl-v1.3.ri | Bin 0 -> 278528
>>> bytes
>>
>> There are two types of platforms, the ones which require the Intel
>> firmware to be signed with a private production key and the ones
>> that
>> are signed with the SOF community key.
>>
>> if we have a single directory, then how do we deal with the two
>> cases?
>
> I've not yet upstreamed the community signed versions yet so everything
> is in the intel/sof/platform/key/ directory structure.
>
>> It's not even clear to me which of the two cases are handled here.
>>
>
> Intel signed binaries, since they are in intel/sof/platform/intel
> directory. Community signed will go in intel/sof/platform/community/
> dir.
I don't understand what you're suggesting nor how it would work with the
way the kernel deals with directories. I tried to explain that we need
an intel/sof-production and intel/sof directories, each with generic
names that are symlinked to another location. This helps if you want to
build quirks that select one or the other capabilities by just changing
the firmware directory prefix. Pointers below.
https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L24
https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/loader.c#L269
https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L149
I guess we need to talk off-line since we are evidently not on the same
page or something is missing for people to use this pull request.
>
>>> intel/sof/sof-apl.ri | 1 +
>>> intel/sof/sof-bdw.ri | 1 +
>>> intel/sof/sof-byt.ri | 1 +
>>> intel/sof/sof-cht.ri | 1 +
>>> intel/sof/sof-cml.ri | 1 +
>>> intel/sof/sof-cnl.ri | 1 +
>>> intel/sof/sof-glk.ri | 1 +
>>> intel/sof/sof-icl.ri | 1 +
>>> intel/sof/sof-whl.ri | 1 +
>>
>> unless I am missing something, we don't have any tables in the Linux
>> kernel for the WHL and CML configurations, and IIRC we only generate
>> sof-cnl.ri. Is there actually a user for sof-whl.ri and sof-cml.ri?
>>
>
> There are glk users hence the addition of whl and cml.
glk has nothing to do with whl and cml. Not sure if there is a typo or
something I missed in your reply?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
2019-07-30 21:09 ` Pierre-Louis Bossart
@ 2019-07-30 21:19 ` Josh Boyer
2019-07-31 10:06 ` Liam Girdwood
0 siblings, 1 reply; 5+ messages in thread
From: Josh Boyer @ 2019-07-30 21:19 UTC (permalink / raw)
To: Pierre-Louis Bossart; +Cc: Liam Girdwood, alsa-devel, Linux Firmware, SOF
On Tue, Jul 30, 2019 at 5:09 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
> >>> ----------------------------------------------------------------
> >>> Liam Girdwood (1):
> >>> sof: Add Intel SOF V1.3 release firmware binaries.
> >>>
> >>> LICENCE.sof | 1090
> >>> ++++++++++++++++++++++++++
> >>
> >> Humm, that LICENSE file needs to be double-checked. Is there any
> >> reason
> >> why the text of this LICENSE.sof is different the usual text, e.g.
> >> from
> >> the LICENSE.adsp_sst?
> >
> > LICENCE.adsp_sst is for the closed source firmware and LICENCE.sof is
> > for SOF. The key difference is the removal of Intel binary FW licence
> > and addition of BSD 3c, MIT, ISC and BSD 2c from SOF LICENCE file. Both
> > files are the same wrt newlib.
>
> I would kindly ask that you run this by legal.
>
> The BSD license is provided for the source files, it's a stretch to say
> that the license extends to binaries without a statement that says that
> the binary firmware is only made of those source files, unmodified and
> without proprietary extensions. And to the best of my knowledge the
> newlib dependencies do not apply when compiling with XCC.
>
> >> * No reverse engineering, decompilation, or disassembly of this
> >> software is
> >> permitted.
> >
> > I'm not following why we need the reverse engineering conditions for
> > opensource binaries.
>
> me neither, that's why I stated that the model has to be different from SST.
>
>
> >> and the DISCLAIMER part, both of which seem pretty important to me.
> >
> > Disclaimer is in BSD 3 clause and MIT licence - exact same as the
> > sources.
>
> Maybe I am splitting hair, but I'd like a professional opinion on that
> license file. Better safe than sorry. I had GKH tell me on Friday to fix
> a (c) 2017-19 and use (c) 2017-2019...
>
> >>
> >> IANAL, but seeing only a patent clause looks odd. There should be a
> >> mention of redistribution and a clear disclaimer (not sure about the
> >> reverse engineering parts since the code is available it makes no
> >> sense).
> >
> > Patent clause is exactly the same as SST FW.
> >
> >>
> >>> WHENCE | 33 +
> >>> intel/sof/apl/intel/sof-apl-v1.3.ri | Bin 0 -> 270336
> >>> bytes
> >>> intel/sof/bdw/sof-bdw-v1.3.ri | Bin 0 -> 100144
> >>> bytes
> >>> intel/sof/byt/sof-byt-v1.3.ri | Bin 0 -> 89668
> >>> bytes
> >>> intel/sof/cht/sof-cht-v1.3.ri | Bin 0 -> 90484
> >>> bytes
> >>> intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri | Bin 0 -> 274432
> >>> bytes
> >>> intel/sof/icl/intel/sof-icl-v1.3.ri | Bin 0 -> 278528
> >>> bytes
> >>
> >> There are two types of platforms, the ones which require the Intel
> >> firmware to be signed with a private production key and the ones
> >> that
> >> are signed with the SOF community key.
> >>
> >> if we have a single directory, then how do we deal with the two
> >> cases?
> >
> > I've not yet upstreamed the community signed versions yet so everything
> > is in the intel/sof/platform/key/ directory structure.
> >
> >> It's not even clear to me which of the two cases are handled here.
> >>
> >
> > Intel signed binaries, since they are in intel/sof/platform/intel
> > directory. Community signed will go in intel/sof/platform/community/
> > dir.
>
> I don't understand what you're suggesting nor how it would work with the
> way the kernel deals with directories. I tried to explain that we need
> an intel/sof-production and intel/sof directories, each with generic
> names that are symlinked to another location. This helps if you want to
> build quirks that select one or the other capabilities by just changing
> the firmware directory prefix. Pointers below.
>
> https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L24
>
> https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/loader.c#L269
>
> https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L149
>
> I guess we need to talk off-line since we are evidently not on the same
> page or something is missing for people to use this pull request.
I suggest you guys do that. At the moment, I'm not pulling anything
related to this until it has a signoff from both you and Liam in the
commit logs at a minimum.
josh
> >>> intel/sof/sof-apl.ri | 1 +
> >>> intel/sof/sof-bdw.ri | 1 +
> >>> intel/sof/sof-byt.ri | 1 +
> >>> intel/sof/sof-cht.ri | 1 +
> >>> intel/sof/sof-cml.ri | 1 +
> >>> intel/sof/sof-cnl.ri | 1 +
> >>> intel/sof/sof-glk.ri | 1 +
> >>> intel/sof/sof-icl.ri | 1 +
> >>> intel/sof/sof-whl.ri | 1 +
> >>
> >> unless I am missing something, we don't have any tables in the Linux
> >> kernel for the WHL and CML configurations, and IIRC we only generate
> >> sof-cnl.ri. Is there actually a user for sof-whl.ri and sof-cml.ri?
> >>
> >
> > There are glk users hence the addition of whl and cml.
>
> glk has nothing to do with whl and cml. Not sure if there is a typo or
> something I missed in your reply?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
2019-07-30 21:19 ` Josh Boyer
@ 2019-07-31 10:06 ` Liam Girdwood
0 siblings, 0 replies; 5+ messages in thread
From: Liam Girdwood @ 2019-07-31 10:06 UTC (permalink / raw)
To: Josh Boyer, Pierre-Louis Bossart; +Cc: alsa-devel, Linux Firmware, SOF
On Tue, 2019-07-30 at 17:19 -0400, Josh Boyer wrote:
> > I don't understand what you're suggesting nor how it would work
> > with the
> > way the kernel deals with directories. I tried to explain that we
> > need
> > an intel/sof-production and intel/sof directories, each with
> > generic
> > names that are symlinked to another location. This helps if you
> > want to
> > build quirks that select one or the other capabilities by just
> > changing
> > the firmware directory prefix. Pointers below.
> >
> > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L24
> >
> > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/loader.c#L269
> >
> > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4eeaa1eb1c/sound/soc/sof/sof-pci-dev.c#L149
So the commit did support this, but it would put all "production"
signed binaries at the intel/sof/ level via soft links (to be
automatically loaded by the driver as the default).
A subsequent commit would have added the community signed images. I
planned to link community signed binaries at the intel/sof/community
level since most users would use the production signed images by
default (and would not need to use a module param to select). My
assumption was that machines using community signed by default would
have this in their default_fw_path ?
> >
> > I guess we need to talk off-line since we are evidently not on the
> > same
> > page or something is missing for people to use this pull request.
>
> I suggest you guys do that. At the moment, I'm not pulling anything
> related to this until it has a signoff from both you and Liam in the
> commit logs at a minimum.
Yep, no problem - Pierre and I will refine and resend shortly. I also
need to remove links for aliases.
Thanks
Liam
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-07-31 10:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <af2d45578f7cdf908eb83cad3371b41315b7b5c4.camel@linux.intel.com>
2019-07-30 16:16 ` [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries Pierre-Louis Bossart
2019-07-30 18:11 ` Liam Girdwood
2019-07-30 21:09 ` Pierre-Louis Bossart
2019-07-30 21:19 ` Josh Boyer
2019-07-31 10:06 ` Liam Girdwood
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.