* accessing ath10k calibration data @ 2016-09-09 17:35 Marty Faltesek 2016-09-09 17:39 ` Adrian Chadd 0 siblings, 1 reply; 12+ messages in thread From: Marty Faltesek @ 2016-09-09 17:35 UTC (permalink / raw) To: ath10k Is there a way to access calibration data without having to start an AP (or client)? Thanks, Marty _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-09 17:35 accessing ath10k calibration data Marty Faltesek @ 2016-09-09 17:39 ` Adrian Chadd 2016-09-09 17:42 ` Marty Faltesek 0 siblings, 1 reply; 12+ messages in thread From: Adrian Chadd @ 2016-09-09 17:39 UTC (permalink / raw) To: Marty Faltesek; +Cc: ath10k Hi, It's just in OTP? You should be able to read the OTP data without needing a STA/AP up? -a On 9 September 2016 at 10:35, Marty Faltesek <mfaltesek@google.com> wrote: > Is there a way to access calibration data without having to start an > AP (or client)? > > Thanks, > > Marty > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-09 17:39 ` Adrian Chadd @ 2016-09-09 17:42 ` Marty Faltesek 2016-09-12 8:50 ` Michal Kazior 0 siblings, 1 reply; 12+ messages in thread From: Marty Faltesek @ 2016-09-09 17:42 UTC (permalink / raw) To: Adrian Chadd, ath10k It's blocked by the code below which I tried to ifdef out, but then it returns all 0's. diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c index 8b01e3e..bb8b7ec 100644 --- a/drivers/net/wireless/ath/ath10k/debug.c +++ b/drivers/net/wireless/ath/ath10k/debug.c @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file) int ret; mutex_lock(&ar->conf_mutex); - +#if 0 if (ar->state != ATH10K_STATE_ON && ar->state != ATH10K_STATE_UTF) { ret = -ENETDOWN; goto err; } +#endif On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > It's just in OTP? You should be able to read the OTP data without > needing a STA/AP up? > > > -a > > > On 9 September 2016 at 10:35, Marty Faltesek <mfaltesek@google.com> wrote: >> Is there a way to access calibration data without having to start an >> AP (or client)? >> >> Thanks, >> >> Marty >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-09 17:42 ` Marty Faltesek @ 2016-09-12 8:50 ` Michal Kazior 2016-09-12 19:47 ` Marty Faltesek 2016-09-12 22:20 ` Marty Faltesek 0 siblings, 2 replies; 12+ messages in thread From: Michal Kazior @ 2016-09-12 8:50 UTC (permalink / raw) To: Marty Faltesek; +Cc: Adrian Chadd, ath10k On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: > It's blocked by the code below which I tried to ifdef out, but then it > returns all 0's. > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c > b/drivers/net/wireless/ath/ath10k/debug.c > index 8b01e3e..bb8b7ec 100644 > --- a/drivers/net/wireless/ath/ath10k/debug.c > +++ b/drivers/net/wireless/ath/ath10k/debug.c > @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct > inode *inode, struct file *file) > int ret; > > mutex_lock(&ar->conf_mutex); > - > +#if 0 > if (ar->state != ATH10K_STATE_ON && > ar->state != ATH10K_STATE_UTF) { > ret = -ENETDOWN; > goto err; > } > +#endif This won't work. The driver needs to go through ath10k_start(), i.e. firmware must be loaded. Cal data is cooked as part of that. You could get away with just `ifconfig wlan0 up`. You don't need to connect or anything. I guess the driver *could* cache the end resulting cal data when the device is probed and re-use it in subsequent firmware boot-up attempts (instead of re-computing it) making it available when the device is stopped as well. Any volunteers to try *and* test if it doesn't break anything? :) > On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd <adrian@freebsd.org> wrote: >> Hi, >> >> It's just in OTP? You should be able to read the OTP data without >> needing a STA/AP up? I would argue with the "just OTP" at least from the driver-device protocol point of view. Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-12 8:50 ` Michal Kazior @ 2016-09-12 19:47 ` Marty Faltesek 2016-09-13 10:46 ` Valo, Kalle 2016-09-12 22:20 ` Marty Faltesek 1 sibling, 1 reply; 12+ messages in thread From: Marty Faltesek @ 2016-09-12 19:47 UTC (permalink / raw) To: Michal Kazior; +Cc: Adrian Chadd, ath10k On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior@tieto.com> wrote: > On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: >> It's blocked by the code below which I tried to ifdef out, but then it >> returns all 0's. >> >> diff --git a/drivers/net/wireless/ath/ath10k/debug.c >> b/drivers/net/wireless/ath/ath10k/debug.c >> index 8b01e3e..bb8b7ec 100644 >> --- a/drivers/net/wireless/ath/ath10k/debug.c >> +++ b/drivers/net/wireless/ath/ath10k/debug.c >> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct >> inode *inode, struct file *file) >> int ret; >> >> mutex_lock(&ar->conf_mutex); >> - >> +#if 0 >> if (ar->state != ATH10K_STATE_ON && >> ar->state != ATH10K_STATE_UTF) { >> ret = -ENETDOWN; >> goto err; >> } >> +#endif > > This won't work. The driver needs to go through ath10k_start(), i.e. > firmware must be loaded. Cal data is cooked as part of that. > > You could get away with just `ifconfig wlan0 up`. You don't need to > connect or anything. This does not work: hexdump: ./kernel/debug/ieee80211/phy1/ath10k/cal_data: Network is down But it works after starting the AP. Are you sure about what you said? > > I guess the driver *could* cache the end resulting cal data when the > device is probed and re-use it in subsequent firmware boot-up attempts > (instead of re-computing it) making it available when the device is > stopped as well. Any volunteers to try *and* test if it doesn't break > anything? :) This might break what we are trying to accomplish, which is read the calibration data and search for mis-calibrated hardware, and if found, apply a fix. > > >> On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd <adrian@freebsd.org> wrote: >>> Hi, >>> >>> It's just in OTP? You should be able to read the OTP data without >>> needing a STA/AP up? > > I would argue with the "just OTP" at least from the driver-device > protocol point of view. > > > Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-12 19:47 ` Marty Faltesek @ 2016-09-13 10:46 ` Valo, Kalle 2016-09-13 20:49 ` Marty Faltesek 0 siblings, 1 reply; 12+ messages in thread From: Valo, Kalle @ 2016-09-13 10:46 UTC (permalink / raw) To: Marty Faltesek; +Cc: Adrian Chadd, michal.kazior, ath10k Marty Faltesek <mfaltesek@google.com> writes: > On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior@tieto.com> wrote: >> On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: >>> It's blocked by the code below which I tried to ifdef out, but then it >>> returns all 0's. >>> >>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c >>> b/drivers/net/wireless/ath/ath10k/debug.c >>> index 8b01e3e..bb8b7ec 100644 >>> --- a/drivers/net/wireless/ath/ath10k/debug.c >>> +++ b/drivers/net/wireless/ath/ath10k/debug.c >>> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct >>> inode *inode, struct file *file) >>> int ret; >>> >>> mutex_lock(&ar->conf_mutex); >>> - >>> +#if 0 >>> if (ar->state != ATH10K_STATE_ON && >>> ar->state != ATH10K_STATE_UTF) { >>> ret = -ENETDOWN; >>> goto err; >>> } >>> +#endif >> >> This won't work. The driver needs to go through ath10k_start(), i.e. >> firmware must be loaded. Cal data is cooked as part of that. >> >> You could get away with just `ifconfig wlan0 up`. You don't need to >> connect or anything. > > This does not work: > > hexdump: ./kernel/debug/ieee80211/phy1/ath10k/cal_data: Network is down > > But it works after starting the AP. Are you sure about what you said? It should work: # ip link show wlan0 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:03:7f:48:d6:05 brd ff:ff:ff:ff:ff:ff # ip link set wlan0 up # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data # ip link set wlan0 down # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data hexdump: /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data: Network is down # What's odd is that I got a file with zero bytes, but no time to investigate it now. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-13 10:46 ` Valo, Kalle @ 2016-09-13 20:49 ` Marty Faltesek 2016-09-13 20:50 ` Adrian Chadd 2016-09-14 5:01 ` Valo, Kalle 0 siblings, 2 replies; 12+ messages in thread From: Marty Faltesek @ 2016-09-13 20:49 UTC (permalink / raw) To: Valo, Kalle; +Cc: Adrian Chadd, michal.kazior, ath10k Hey Kalle OK this does work for me after all. Thanks. I wrote a patch to cache cal_data only while the core is off. I don't need it now, but wondering if there is any benefit to submitting it? thanks, Marty On Tue, Sep 13, 2016 at 6:46 AM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote: > Marty Faltesek <mfaltesek@google.com> writes: > >> On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior@tieto.com> wrote: >>> On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: >>>> It's blocked by the code below which I tried to ifdef out, but then it >>>> returns all 0's. >>>> >>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c >>>> b/drivers/net/wireless/ath/ath10k/debug.c >>>> index 8b01e3e..bb8b7ec 100644 >>>> --- a/drivers/net/wireless/ath/ath10k/debug.c >>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c >>>> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct >>>> inode *inode, struct file *file) >>>> int ret; >>>> >>>> mutex_lock(&ar->conf_mutex); >>>> - >>>> +#if 0 >>>> if (ar->state != ATH10K_STATE_ON && >>>> ar->state != ATH10K_STATE_UTF) { >>>> ret = -ENETDOWN; >>>> goto err; >>>> } >>>> +#endif >>> >>> This won't work. The driver needs to go through ath10k_start(), i.e. >>> firmware must be loaded. Cal data is cooked as part of that. >>> >>> You could get away with just `ifconfig wlan0 up`. You don't need to >>> connect or anything. >> >> This does not work: >> >> hexdump: ./kernel/debug/ieee80211/phy1/ath10k/cal_data: Network is down >> >> But it works after starting the AP. Are you sure about what you said? > > It should work: > > # ip link show wlan0 > 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 > link/ether 00:03:7f:48:d6:05 brd ff:ff:ff:ff:ff:ff > # ip link set wlan0 up > # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data > # ip link set wlan0 down > # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data > hexdump: /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data: Network is down > # > > What's odd is that I got a file with zero bytes, but no time to > investigate it now. > > -- > Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-13 20:49 ` Marty Faltesek @ 2016-09-13 20:50 ` Adrian Chadd 2016-09-14 5:01 ` Valo, Kalle 1 sibling, 0 replies; 12+ messages in thread From: Adrian Chadd @ 2016-09-13 20:50 UTC (permalink / raw) To: Marty Faltesek; +Cc: Valo, Kalle, michal.kazior, ath10k Yes! :) -a On 13 September 2016 at 13:49, Marty Faltesek <mfaltesek@google.com> wrote: > Hey Kalle > > OK this does work for me after all. Thanks. > > I wrote a patch to cache cal_data only while the core is off. I don't > need it now, but wondering if there is any benefit > to submitting it? > > thanks, > > Marty > > > > > > On Tue, Sep 13, 2016 at 6:46 AM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote: >> Marty Faltesek <mfaltesek@google.com> writes: >> >>> On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior@tieto.com> wrote: >>>> On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: >>>>> It's blocked by the code below which I tried to ifdef out, but then it >>>>> returns all 0's. >>>>> >>>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c >>>>> b/drivers/net/wireless/ath/ath10k/debug.c >>>>> index 8b01e3e..bb8b7ec 100644 >>>>> --- a/drivers/net/wireless/ath/ath10k/debug.c >>>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c >>>>> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct >>>>> inode *inode, struct file *file) >>>>> int ret; >>>>> >>>>> mutex_lock(&ar->conf_mutex); >>>>> - >>>>> +#if 0 >>>>> if (ar->state != ATH10K_STATE_ON && >>>>> ar->state != ATH10K_STATE_UTF) { >>>>> ret = -ENETDOWN; >>>>> goto err; >>>>> } >>>>> +#endif >>>> >>>> This won't work. The driver needs to go through ath10k_start(), i.e. >>>> firmware must be loaded. Cal data is cooked as part of that. >>>> >>>> You could get away with just `ifconfig wlan0 up`. You don't need to >>>> connect or anything. >>> >>> This does not work: >>> >>> hexdump: ./kernel/debug/ieee80211/phy1/ath10k/cal_data: Network is down >>> >>> But it works after starting the AP. Are you sure about what you said? >> >> It should work: >> >> # ip link show wlan0 >> 5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 >> link/ether 00:03:7f:48:d6:05 brd ff:ff:ff:ff:ff:ff >> # ip link set wlan0 up >> # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data >> # ip link set wlan0 down >> # hexdump /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data >> hexdump: /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data: Network is down >> # >> >> What's odd is that I got a file with zero bytes, but no time to >> investigate it now. >> >> -- >> Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-13 20:49 ` Marty Faltesek 2016-09-13 20:50 ` Adrian Chadd @ 2016-09-14 5:01 ` Valo, Kalle 2016-09-14 23:54 ` Marty Faltesek 1 sibling, 1 reply; 12+ messages in thread From: Valo, Kalle @ 2016-09-14 5:01 UTC (permalink / raw) To: Marty Faltesek; +Cc: Adrian Chadd, michal.kazior, ath10k Marty Faltesek <mfaltesek@google.com> writes: > OK this does work for me after all. Thanks. Great. > I wrote a patch to cache cal_data only while the core is off. I don't > need it now, but wondering if there is any benefit > to submitting it? I guess Adrian already answered that :) So please do submit and let's take a look at it. -- Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-14 5:01 ` Valo, Kalle @ 2016-09-14 23:54 ` Marty Faltesek 2016-09-15 11:24 ` Michal Kazior 0 siblings, 1 reply; 12+ messages in thread From: Marty Faltesek @ 2016-09-14 23:54 UTC (permalink / raw) To: Valo, Kalle; +Cc: Adrian Chadd, michal.kazior, ath10k I sent out the patch. I ran into another related issue. Let me explain what we are trying to do: We want to examine cal_data for a possibly mis-calibrated OTP, and if so, patch it and store the result in /tmp (creating a symlink from /ilb/firmware/ath10k/cal-pci-0001:01:00.0.bin to /tmp). But ath10k_fetch_cal_file() is only read once at load time, so I've modified the code to call this function from ath10k_download_cal_file() so that the driver catches the modified cal_data. This seems to work based on the read back of the patched cal_data, but is it the right approach, or is there a better or cleaner way? On Wed, Sep 14, 2016 at 1:01 AM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote: > Marty Faltesek <mfaltesek@google.com> writes: > >> OK this does work for me after all. Thanks. > > Great. > >> I wrote a patch to cache cal_data only while the core is off. I don't >> need it now, but wondering if there is any benefit >> to submitting it? > > I guess Adrian already answered that :) So please do submit and let's > take a look at it. > > -- > Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-14 23:54 ` Marty Faltesek @ 2016-09-15 11:24 ` Michal Kazior 0 siblings, 0 replies; 12+ messages in thread From: Michal Kazior @ 2016-09-15 11:24 UTC (permalink / raw) To: Marty Faltesek; +Cc: Valo, Kalle, Adrian Chadd, ath10k On 15 September 2016 at 01:54, Marty Faltesek <mfaltesek@google.com> wrote: > I sent out the patch. > > I ran into another related issue. Let me explain what we are trying to do: > > We want to examine cal_data for a possibly mis-calibrated OTP, and if > so, patch it and store > the result in /tmp (creating a symlink from > /ilb/firmware/ath10k/cal-pci-0001:01:00.0.bin to /tmp). > > But ath10k_fetch_cal_file() is only read once at load time, so I've > modified the code to call this function from > ath10k_download_cal_file() > so that the driver catches the modified cal_data. This seems to work > based on the read back of the patched cal_data, but is it the right > approach, or is there a better or cleaner way? The reason why firmware files (including cal, et al) in memory is to guarantee firmware reloads result in the same set of hw capabilities which can be advertised during mac80211 register time. Changing them in runtime is not really clean. I don't really have a clean answer for you. Do you really need to keep given driver instance running without interruption? At what point do you verify caldata? If it's before upping interfaces you could either unload/load the driver or unbind/bind the device itself to force it to read firmware files anew. Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accessing ath10k calibration data 2016-09-12 8:50 ` Michal Kazior 2016-09-12 19:47 ` Marty Faltesek @ 2016-09-12 22:20 ` Marty Faltesek 1 sibling, 0 replies; 12+ messages in thread From: Marty Faltesek @ 2016-09-12 22:20 UTC (permalink / raw) To: Michal Kazior; +Cc: Adrian Chadd, ath10k On Mon, Sep 12, 2016 at 4:50 AM, Michal Kazior <michal.kazior@tieto.com> wrote: > On 9 September 2016 at 19:42, Marty Faltesek <mfaltesek@google.com> wrote: >> It's blocked by the code below which I tried to ifdef out, but then it >> returns all 0's. >> >> diff --git a/drivers/net/wireless/ath/ath10k/debug.c >> b/drivers/net/wireless/ath/ath10k/debug.c >> index 8b01e3e..bb8b7ec 100644 >> --- a/drivers/net/wireless/ath/ath10k/debug.c >> +++ b/drivers/net/wireless/ath/ath10k/debug.c >> @@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct >> inode *inode, struct file *file) >> int ret; >> >> mutex_lock(&ar->conf_mutex); >> - >> +#if 0 >> if (ar->state != ATH10K_STATE_ON && >> ar->state != ATH10K_STATE_UTF) { >> ret = -ENETDOWN; >> goto err; >> } >> +#endif > > This won't work. The driver needs to go through ath10k_start(), i.e. > firmware must be loaded. Cal data is cooked as part of that. > > You could get away with just `ifconfig wlan0 up`. You don't need to > connect or anything. > > I guess the driver *could* cache the end resulting cal data when the > device is probed and re-use it in subsequent firmware boot-up attempts > (instead of re-computing it) making it available when the device is > stopped as well. Any volunteers to try *and* test if it doesn't break > anything? :) > I see what you mean now. This might actually work for us. I'll give it a shot and see. thanks, Marty _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-09-15 11:24 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-09 17:35 accessing ath10k calibration data Marty Faltesek 2016-09-09 17:39 ` Adrian Chadd 2016-09-09 17:42 ` Marty Faltesek 2016-09-12 8:50 ` Michal Kazior 2016-09-12 19:47 ` Marty Faltesek 2016-09-13 10:46 ` Valo, Kalle 2016-09-13 20:49 ` Marty Faltesek 2016-09-13 20:50 ` Adrian Chadd 2016-09-14 5:01 ` Valo, Kalle 2016-09-14 23:54 ` Marty Faltesek 2016-09-15 11:24 ` Michal Kazior 2016-09-12 22:20 ` Marty Faltesek
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.