* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
@ 2010-10-19 17:55 Larry Finger
2010-10-19 18:02 ` John W. Linville
2010-10-19 21:04 ` Michael Büsch
0 siblings, 2 replies; 9+ messages in thread
From: Larry Finger @ 2010-10-19 17:55 UTC (permalink / raw)
To: b43-dev
MMIO log traces obtained using the Broadcom wl hybrid driver show that
the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
if non-zero. Similar code found in other drivers such as ipw2100 show
this operation is needed to keep PCI Tx retries from interfering with
C3 CPU state. There are no known cases where omission of this code has
caused a problem, but this patch is offered just in case such a situation
occurs.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
No particular urgency for this patch.
Larry
---
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===================================================================
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c
+++ wireless-testing/drivers/ssb/driver_pcicore.c
@@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
{
u8 lat;
+ u32 val;
if (dev->bus->ops != &ssb_pcicore_pciops) {
/* This is not a device on the PCI-core bridge. */
@@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
return;
}
+ /* Disable the RETRY_TIMEOUT register (0x41) to keep
+ * PCI Tx retries from interfering with C3 CPU state */
+ pci_read_config_dword(pci_dev, 0x40, &val);
+ if ((val & 0x0000ff00) != 0)
+ pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
+
/* Enable PCI bridge BAR1 prefetch and burst */
pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-10-19 17:55 [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration Larry Finger
@ 2010-10-19 18:02 ` John W. Linville
2010-10-19 18:21 ` Larry Finger
2010-10-19 21:04 ` Michael Büsch
1 sibling, 1 reply; 9+ messages in thread
From: John W. Linville @ 2010-10-19 18:02 UTC (permalink / raw)
To: b43-dev
On Tue, Oct 19, 2010 at 12:55:55PM -0500, Larry Finger wrote:
> MMIO log traces obtained using the Broadcom wl hybrid driver show that
> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
> if non-zero. Similar code found in other drivers such as ipw2100 show
> this operation is needed to keep PCI Tx retries from interfering with
> C3 CPU state. There are no known cases where omission of this code has
> caused a problem, but this patch is offered just in case such a situation
> occurs.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> No particular urgency for this patch.
>
> Larry
I nearly missed it! Please do Cc linux-wireless at vger.kernel.org on patches.
John
--
John W. Linville Someday the world will need a hero, and you
linville at tuxdriver.com might be all we have. Be ready.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-10-19 18:02 ` John W. Linville
@ 2010-10-19 18:21 ` Larry Finger
0 siblings, 0 replies; 9+ messages in thread
From: Larry Finger @ 2010-10-19 18:21 UTC (permalink / raw)
To: b43-dev
On 10/19/2010 01:02 PM, John W. Linville wrote:
> On Tue, Oct 19, 2010 at 12:55:55PM -0500, Larry Finger wrote:
>> MMIO log traces obtained using the Broadcom wl hybrid driver show that
>> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
>> if non-zero. Similar code found in other drivers such as ipw2100 show
>> this operation is needed to keep PCI Tx retries from interfering with
>> C3 CPU state. There are no known cases where omission of this code has
>> caused a problem, but this patch is offered just in case such a situation
>> occurs.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> John,
>>
>> No particular urgency for this patch.
>>
>> Larry
>
> I nearly missed it! Please do Cc linux-wireless at vger.kernel.org on patches.
Sorry. I guess I'm out of practice.
Larry
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-10-19 17:55 [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration Larry Finger
2010-10-19 18:02 ` John W. Linville
@ 2010-10-19 21:04 ` Michael Büsch
2010-11-09 23:09 ` Rafał Miłecki
1 sibling, 1 reply; 9+ messages in thread
From: Michael Büsch @ 2010-10-19 21:04 UTC (permalink / raw)
To: b43-dev
On Tue, 2010-10-19 at 12:55 -0500, Larry Finger wrote:
> MMIO log traces obtained using the Broadcom wl hybrid driver show that
> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
> if non-zero. Similar code found in other drivers such as ipw2100 show
> this operation is needed to keep PCI Tx retries from interfering with
> C3 CPU state. There are no known cases where omission of this code has
> caused a problem, but this patch is offered just in case such a situation
> occurs.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> No particular urgency for this patch.
>
> Larry
> ---
>
> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c
> +++ wireless-testing/drivers/ssb/driver_pcicore.c
> @@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
> static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
> {
> u8 lat;
> + u32 val;
>
> if (dev->bus->ops != &ssb_pcicore_pciops) {
> /* This is not a device on the PCI-core bridge. */
> @@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
> return;
> }
>
> + /* Disable the RETRY_TIMEOUT register (0x41) to keep
> + * PCI Tx retries from interfering with C3 CPU state */
> + pci_read_config_dword(pci_dev, 0x40, &val);
> + if ((val & 0x0000ff00) != 0)
> + pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
> +
> /* Enable PCI bridge BAR1 prefetch and burst */
> pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
Hm, do you realize that this function will only be executed for PCI
devices that live on top of a native SSB bus? Is that intentional?
It won't affect normal broadcom wireless PCI devices.
It will only have an affect on a broadcom wireless PCI device that lives
behind a SSB->PCI bridge on an embedded device.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-10-19 21:04 ` Michael Büsch
@ 2010-11-09 23:09 ` Rafał Miłecki
2010-11-09 23:13 ` Michael Büsch
0 siblings, 1 reply; 9+ messages in thread
From: Rafał Miłecki @ 2010-11-09 23:09 UTC (permalink / raw)
To: b43-dev
2010/10/19 Michael B?sch <mb@bu3sch.de>:
> On Tue, 2010-10-19 at 12:55 -0500, Larry Finger wrote:
>> MMIO log traces obtained using the Broadcom wl hybrid driver show that
>> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
>> if non-zero. Similar code found in other drivers such as ipw2100 show
>> this operation is needed to keep PCI Tx retries from interfering with
>> C3 CPU state. There are no known cases where omission of this code has
>> caused a problem, but this patch is offered just in case such a situation
>> occurs.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> John,
>>
>> No particular urgency for this patch.
>>
>> Larry
>> ---
>>
>> Index: wireless-testing/drivers/ssb/driver_pcicore.c
>> ===================================================================
>> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c
>> +++ wireless-testing/drivers/ssb/driver_pcicore.c
>> @@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
>> ?static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
>> ?{
>> ? ? ? u8 lat;
>> + ? ? u32 val;
>>
>> ? ? ? if (dev->bus->ops != &ssb_pcicore_pciops) {
>> ? ? ? ? ? ? ? /* This is not a device on the PCI-core bridge. */
>> @@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
>> ? ? ? ? ? ? ? return;
>> ? ? ? }
>>
>> + ? ? /* Disable the RETRY_TIMEOUT register (0x41) to keep
>> + ? ? ?* PCI Tx retries from interfering with C3 CPU state */
>> + ? ? pci_read_config_dword(pci_dev, 0x40, &val);
>> + ? ? if ((val & 0x0000ff00) != 0)
>> + ? ? ? ? ? ? pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
>> +
>> ? ? ? /* Enable PCI bridge BAR1 prefetch and burst */
>> ? ? ? pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
>
>
> Hm, do you realize that this function will only be executed for PCI
> devices that live on top of a native SSB bus? Is that intentional?
>
> It won't affect normal broadcom wireless PCI devices.
> It will only have an affect on a broadcom wireless PCI device that lives
> behind a SSB->PCI bridge on an embedded device.
Is this patch needed? Shouldn't this be replaced by second version
affecting "normal devices"?
I can see both applied to wireless-testing.
--
Rafa?
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-11-09 23:09 ` Rafał Miłecki
@ 2010-11-09 23:13 ` Michael Büsch
2010-11-10 17:37 ` John W. Linville
0 siblings, 1 reply; 9+ messages in thread
From: Michael Büsch @ 2010-11-09 23:13 UTC (permalink / raw)
To: b43-dev
On Wed, 2010-11-10 at 00:09 +0100, Rafa? Mi?ecki wrote:
> 2010/10/19 Michael B?sch <mb@bu3sch.de>:
> > On Tue, 2010-10-19 at 12:55 -0500, Larry Finger wrote:
> >> MMIO log traces obtained using the Broadcom wl hybrid driver show that
> >> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
> >> if non-zero. Similar code found in other drivers such as ipw2100 show
> >> this operation is needed to keep PCI Tx retries from interfering with
> >> C3 CPU state. There are no known cases where omission of this code has
> >> caused a problem, but this patch is offered just in case such a situation
> >> occurs.
> >>
> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >> ---
> >>
> >> John,
> >>
> >> No particular urgency for this patch.
> >>
> >> Larry
> >> ---
> >>
> >> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> >> ===================================================================
> >> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c
> >> +++ wireless-testing/drivers/ssb/driver_pcicore.c
> >> @@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
> >> static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
> >> {
> >> u8 lat;
> >> + u32 val;
> >>
> >> if (dev->bus->ops != &ssb_pcicore_pciops) {
> >> /* This is not a device on the PCI-core bridge. */
> >> @@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
> >> return;
> >> }
> >>
> >> + /* Disable the RETRY_TIMEOUT register (0x41) to keep
> >> + * PCI Tx retries from interfering with C3 CPU state */
> >> + pci_read_config_dword(pci_dev, 0x40, &val);
> >> + if ((val & 0x0000ff00) != 0)
> >> + pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
> >> +
> >> /* Enable PCI bridge BAR1 prefetch and burst */
> >> pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
> >
> >
> > Hm, do you realize that this function will only be executed for PCI
> > devices that live on top of a native SSB bus? Is that intentional?
> >
> > It won't affect normal broadcom wireless PCI devices.
> > It will only have an affect on a broadcom wireless PCI device that lives
> > behind a SSB->PCI bridge on an embedded device.
>
> Is this patch needed? Shouldn't this be replaced by second version
> affecting "normal devices"?
>
> I can see both applied to wireless-testing.
They certainly should _not_ be applied both.
John, some fixing is needed. Please remove this patch.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-11-09 23:13 ` Michael Büsch
@ 2010-11-10 17:37 ` John W. Linville
2010-11-10 21:52 ` Michael Büsch
0 siblings, 1 reply; 9+ messages in thread
From: John W. Linville @ 2010-11-10 17:37 UTC (permalink / raw)
To: b43-dev
On Wed, Nov 10, 2010 at 12:13:35AM +0100, Michael B?sch wrote:
> On Wed, 2010-11-10 at 00:09 +0100, Rafa? Mi?ecki wrote:
> > 2010/10/19 Michael B?sch <mb@bu3sch.de>:
> > > On Tue, 2010-10-19 at 12:55 -0500, Larry Finger wrote:
> > >> MMIO log traces obtained using the Broadcom wl hybrid driver show that
> > >> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
> > >> if non-zero. Similar code found in other drivers such as ipw2100 show
> > >> this operation is needed to keep PCI Tx retries from interfering with
> > >> C3 CPU state. There are no known cases where omission of this code has
> > >> caused a problem, but this patch is offered just in case such a situation
> > >> occurs.
> > >>
> > >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> > >> ---
> > >>
> > >> John,
> > >>
> > >> No particular urgency for this patch.
> > >>
> > >> Larry
> > >> ---
> > >>
> > >> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> > >> ===================================================================
> > >> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c
> > >> +++ wireless-testing/drivers/ssb/driver_pcicore.c
> > >> @@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
> > >> static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
> > >> {
> > >> u8 lat;
> > >> + u32 val;
> > >>
> > >> if (dev->bus->ops != &ssb_pcicore_pciops) {
> > >> /* This is not a device on the PCI-core bridge. */
> > >> @@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
> > >> return;
> > >> }
> > >>
> > >> + /* Disable the RETRY_TIMEOUT register (0x41) to keep
> > >> + * PCI Tx retries from interfering with C3 CPU state */
> > >> + pci_read_config_dword(pci_dev, 0x40, &val);
> > >> + if ((val & 0x0000ff00) != 0)
> > >> + pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
> > >> +
> > >> /* Enable PCI bridge BAR1 prefetch and burst */
> > >> pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
> > >
> > >
> > > Hm, do you realize that this function will only be executed for PCI
> > > devices that live on top of a native SSB bus? Is that intentional?
> > >
> > > It won't affect normal broadcom wireless PCI devices.
> > > It will only have an affect on a broadcom wireless PCI device that lives
> > > behind a SSB->PCI bridge on an embedded device.
> >
> > Is this patch needed? Shouldn't this be replaced by second version
> > affecting "normal devices"?
> >
> > I can see both applied to wireless-testing.
>
> They certainly should _not_ be applied both.
> John, some fixing is needed. Please remove this patch.
Does the other patch handle this case (i.e. devices behind SSB->PCI
bridge)? If so, can you explain how? It looks to me like the code
in ssb_pcihost_register is only called for PCI-attached b43 (or b44)
devices.
Or are you saying the RETRY_TIMEOUT change is inappropriate for a
device behind an SSB->PCI bridge?
John
--
John W. Linville Someday the world will need a hero, and you
linville at tuxdriver.com might be all we have. Be ready.
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-11-10 17:37 ` John W. Linville
@ 2010-11-10 21:52 ` Michael Büsch
2010-11-16 20:40 ` John W. Linville
0 siblings, 1 reply; 9+ messages in thread
From: Michael Büsch @ 2010-11-10 21:52 UTC (permalink / raw)
To: b43-dev
On Wed, 2010-11-10 at 12:37 -0500, John W. Linville wrote:
> On Wed, Nov 10, 2010 at 12:13:35AM +0100, Michael B?sch wrote:
> > On Wed, 2010-11-10 at 00:09 +0100, Rafa? Mi?ecki wrote:
> > > 2010/10/19 Michael B?sch <mb@bu3sch.de>:
> > > > On Tue, 2010-10-19 at 12:55 -0500, Larry Finger wrote:
> > > >> MMIO log traces obtained using the Broadcom wl hybrid driver show that
> > > >> the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared
> > > >> if non-zero. Similar code found in other drivers such as ipw2100 show
> > > >> this operation is needed to keep PCI Tx retries from interfering with
> > > >> C3 CPU state. There are no known cases where omission of this code has
> > > >> caused a problem, but this patch is offered just in case such a situation
> > > >> occurs.
> > > >>
> > > >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> > > >> ---
> > > >>
> > > >> John,
> > > >>
> > > >> No particular urgency for this patch.
> > > >>
> > > >> Larry
> > > >> ---
> > > >>
> > > >> Index: wireless-testing/drivers/ssb/driver_pcicore.c
> > > >> ===================================================================
> > > >> --- wireless-testing.orig/drivers/ssb/driver_pcicore.c
> > > >> +++ wireless-testing/drivers/ssb/driver_pcicore.c
> > > >> @@ -271,6 +271,7 @@ int ssb_pcicore_plat_dev_init(struct pci
> > > >> static void ssb_pcicore_fixup_pcibridge(struct pci_dev *dev)
> > > >> {
> > > >> u8 lat;
> > > >> + u32 val;
> > > >>
> > > >> if (dev->bus->ops != &ssb_pcicore_pciops) {
> > > >> /* This is not a device on the PCI-core bridge. */
> > > >> @@ -288,6 +289,12 @@ static void ssb_pcicore_fixup_pcibridge(
> > > >> return;
> > > >> }
> > > >>
> > > >> + /* Disable the RETRY_TIMEOUT register (0x41) to keep
> > > >> + * PCI Tx retries from interfering with C3 CPU state */
> > > >> + pci_read_config_dword(pci_dev, 0x40, &val);
> > > >> + if ((val & 0x0000ff00) != 0)
> > > >> + pci_write_config_dword(pci_dev, 0x40, val & 0xffff00ff);
> > > >> +
> > > >> /* Enable PCI bridge BAR1 prefetch and burst */
> > > >> pci_write_config_dword(dev, SSB_BAR1_CONTROL, 3);
> > > >
> > > >
> > > > Hm, do you realize that this function will only be executed for PCI
> > > > devices that live on top of a native SSB bus? Is that intentional?
> > > >
> > > > It won't affect normal broadcom wireless PCI devices.
> > > > It will only have an affect on a broadcom wireless PCI device that lives
> > > > behind a SSB->PCI bridge on an embedded device.
> > >
> > > Is this patch needed? Shouldn't this be replaced by second version
> > > affecting "normal devices"?
> > >
> > > I can see both applied to wireless-testing.
> >
> > They certainly should _not_ be applied both.
> > John, some fixing is needed. Please remove this patch.
>
> Does the other patch handle this case (i.e. devices behind SSB->PCI
> bridge)? If so, can you explain how?
Yes. For embedded it goes:
native-ssb -> pci-core -> pci-bridge module -> wireless ssb
For PCI it goes:
native pci bus -> pci-bridge module -> wireless ssb
So you see that the pci bridge module is the bus glue for all SSB
based PCI devices. So we do not need the workaround in the pci-core
driver code. Just in the pci-bridge code (which is
drivers/ssb/pcihost_wrapper.c)
> It looks to me like the code
> in ssb_pcihost_register is only called for PCI-attached b43 (or b44)
> devices.
Yeah. But devices connected to the ssb-pci-core _are_ PCI attached
devices.
> Or are you saying the RETRY_TIMEOUT change is inappropriate for a
> device behind an SSB->PCI bridge?
No. But we already handle that, because the glue code
(pcihost_wrapper.c) is used for both types.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration
2010-11-10 21:52 ` Michael Büsch
@ 2010-11-16 20:40 ` John W. Linville
0 siblings, 0 replies; 9+ messages in thread
From: John W. Linville @ 2010-11-16 20:40 UTC (permalink / raw)
To: b43-dev
On Wed, Nov 10, 2010 at 10:52:33PM +0100, Michael B?sch wrote:
> On Wed, 2010-11-10 at 12:37 -0500, John W. Linville wrote:
> > Does the other patch handle this case (i.e. devices behind SSB->PCI
> > bridge)? If so, can you explain how?
>
> Yes. For embedded it goes:
>
> native-ssb -> pci-core -> pci-bridge module -> wireless ssb
>
> For PCI it goes:
>
> native pci bus -> pci-bridge module -> wireless ssb
>
> So you see that the pci bridge module is the bus glue for all SSB
> based PCI devices. So we do not need the workaround in the pci-core
> driver code. Just in the pci-bridge code (which is
> drivers/ssb/pcihost_wrapper.c)
>
> > It looks to me like the code
> > in ssb_pcihost_register is only called for PCI-attached b43 (or b44)
> > devices.
>
> Yeah. But devices connected to the ssb-pci-core _are_ PCI attached
> devices.
>
> > Or are you saying the RETRY_TIMEOUT change is inappropriate for a
> > device behind an SSB->PCI bridge?
>
> No. But we already handle that, because the glue code
> (pcihost_wrapper.c) is used for both types.
Thanks for the explanation!
--
John W. Linville Someday the world will need a hero, and you
linville at tuxdriver.com might be all we have. Be ready.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-11-16 20:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-19 17:55 [PATCH] ssb: Clear RETRY_TIMEOUT in PCI Configuration Larry Finger
2010-10-19 18:02 ` John W. Linville
2010-10-19 18:21 ` Larry Finger
2010-10-19 21:04 ` Michael Büsch
2010-11-09 23:09 ` Rafał Miłecki
2010-11-09 23:13 ` Michael Büsch
2010-11-10 17:37 ` John W. Linville
2010-11-10 21:52 ` Michael Büsch
2010-11-16 20:40 ` John W. Linville
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).