On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
co-processor, VideoCore. This series reworks how we handle this.
The previous solution makes use of PCI quirks and exporting platform
specific functions. Albeit functional it feels pretty shoehorned. This
proposes an alternative way of handling the triggering of the xHCI chip
initialization trough means of a reset controller.
The benefits are pretty evident: less platform churn in core xHCI code,
and no explicit device dependency management in pcie-brcmstb.
Note that patch #1 depends on another series[1], that was just applied
into the clk maintainer's tree.
The series is based on v5.8-rc3
v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
v2: https://lkml.org/lkml/2020/6/9/875
v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
[1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
---
Changes since v4:
- Adress Andy's comments
Changes since v3:
- Rework dt patch to include root bridge as a separate node
- Update xhci-pci patch now that the xhci dev has a dt node (it was
getting it in the past from its bus)
Changes since v2:
- Add reset to resume routine in xhci-pci
- Correct of refcount in pci-quirks
- Correct typos
- Use include file to define firmware reset IDs
Changes since v1:
- Rework reset controller so it's less USB centric
- Use correct reset controller API in xhci-pci
- Correct typos
Nicolas Saenz Julienne (9):
dt-bindings: reset: Add a binding for the RPi Firmware reset
controller
reset: Add Raspberry Pi 4 firmware reset controller
ARM: dts: bcm2711: Add firmware usb reset node
ARM: dts: bcm2711: Add reset controller to xHCI node
usb: xhci-pci: Add support for reset controllers
Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk"
usb: host: pci-quirks: Bypass xHCI quirks for Raspberry Pi 4
Revert "firmware: raspberrypi: Introduce vl805 init routine"
Revert "PCI: brcmstb: Wait for Raspberry Pi's firmware when present"
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++++
drivers/firmware/Kconfig | 3 +-
drivers/firmware/raspberrypi.c | 61 ---------
drivers/pci/controller/pcie-brcmstb.c | 17 ---
drivers/reset/Kconfig | 11 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-raspberrypi.c | 122 ++++++++++++++++++
drivers/usb/host/pci-quirks.c | 22 ++--
drivers/usb/host/xhci-pci.c | 10 ++
drivers/usb/host/xhci.h | 2 +
.../reset/raspberrypi,firmware-reset.h | 13 ++
include/soc/bcm2835/raspberrypi-firmware.h | 7 -
13 files changed, 215 insertions(+), 97 deletions(-)
create mode 100644 drivers/reset/reset-raspberrypi.c
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
--
2.27.0
Now that the reset driver exposing Raspberry Pi 4's firmware based USB
reset routine is available, let's add the device tree node exposing it.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
---
Changes since v1:
- Update cell nr to match new bindings
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index c7f1d97e69bb..0cef95058fb0 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -83,6 +83,11 @@ expgpio: gpio {
"";
status = "okay";
};
+
+ reset: reset {
+ compatible = "raspberrypi,firmware-reset";
+ #reset-cells = <1>;
+ };
};
&gpio {
--
2.27.0
The board doesn't need the quirks to be run, and takes care of its own
initialization through a reset controller device. So let's bypass them.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
---
Changes since v2:
- Correct reference counting on parent device node
Changes since v1:
- Correct typos
drivers/usb/host/pci-quirks.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 358015328391..977d0b6d7577 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,6 +16,7 @@
#include <linux/export.h>
#include <linux/acpi.h>
#include <linux/dmi.h>
+#include <linux/of.h>
#include "pci-quirks.h"
#include "xhci-ext-caps.h"
@@ -1244,11 +1245,27 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
static void quirk_usb_early_handoff(struct pci_dev *pdev)
{
+ struct device_node *parent;
+ bool is_rpi;
+
/* Skip Netlogic mips SoC's internal PCI USB controller.
* This device does not need/support EHCI/OHCI handoff
*/
if (pdev->vendor == 0x184e) /* vendor Netlogic */
return;
+
+ /*
+ * Bypass the Raspberry Pi 4 controller xHCI controller, things are
+ * taken care of by the board's co-processor.
+ */
+ if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
+ parent = of_get_parent(pdev->bus->dev.of_node);
+ is_rpi = of_device_is_compatible(parent, "brcm,bcm2711-pcie");
+ of_node_put(parent);
+ if (is_rpi)
+ return;
+ }
+
if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
--
2.27.0
Some atypical users of xhci-pci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Acked-by: Mathias Nyman <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
---
Changes since v3:
- Now that DT is fixed we can use the actual xHCI device to get reset
controller (not altering the reviewed-bys as it wasn't an xHCI/reset
controller issue).
Changes since v2:
- Also reset on resume
Changes since v1:
- Use proper reset API
- Make code simpler
drivers/usb/host/xhci-pci.c | 10 ++++++++++
drivers/usb/host/xhci.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index ef513c2fb843..f8b171825dfc 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/acpi.h>
+#include <linux/reset.h>
#include "xhci.h"
#include "xhci-trace.h"
@@ -339,6 +340,7 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
struct xhci_hcd *xhci;
struct usb_hcd *hcd;
struct xhci_driver_data *driver_data;
+ struct reset_control *reset;
driver_data = (struct xhci_driver_data *)id->driver_data;
if (driver_data && driver_data->quirks & XHCI_RENESAS_FW_QUIRK) {
@@ -347,6 +349,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
return retval;
}
+ reset = devm_reset_control_get_optional_exclusive(&dev->dev, NULL);
+ if (IS_ERR(reset))
+ return PTR_ERR(reset);
+ reset_control_reset(reset);
+
/* Prevent runtime suspending between USB-2 and USB-3 initialization */
pm_runtime_get_noresume(&dev->dev);
@@ -364,6 +371,7 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* USB 2.0 roothub is stored in the PCI device now. */
hcd = dev_get_drvdata(&dev->dev);
xhci = hcd_to_xhci(hcd);
+ xhci->reset = reset;
xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev,
pci_name(dev), hcd);
if (!xhci->shared_hcd) {
@@ -515,6 +523,8 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
int retval = 0;
+ reset_control_reset(xhci->reset);
+
/* The BIOS on systems with the Intel Panther Point chipset may or may
* not support xHCI natively. That means that during system resume, it
* may switch the ports back to EHCI so that users can use their
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index c295e8a7f5ae..b22840049ff7 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1770,6 +1770,8 @@ struct xhci_hcd {
/* optional clocks */
struct clk *clk;
struct clk *reg_clk;
+ /* optional reset controller */
+ struct reset_control *reset;
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring *cmd_ring;
--
2.27.0
The firmware running on the RPi VideoCore can be used to reset and
initialize HW controlled by the firmware.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
---
Changes since v2:
- Add include file for reset IDs
Changes since v1:
- Correct cells binding as per Florian's comment
- Change compatible string to be more generic
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++++++++++++++++++
.../reset/raspberrypi,firmware-reset.h | 13 ++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index b48ed875eb8e..23a885af3a28 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -39,6 +39,22 @@ properties:
- compatible
- "#clock-cells"
+ reset:
+ type: object
+
+ properties:
+ compatible:
+ const: raspberrypi,firmware-reset
+
+ "#reset-cells":
+ const: 1
+ description: >
+ The argument is the ID of the firmware reset line to affect.
+
+ required:
+ - compatible
+ - "#reset-cells"
+
additionalProperties: false
required:
@@ -55,5 +71,10 @@ examples:
compatible = "raspberrypi,firmware-clocks";
#clock-cells = <1>;
};
+
+ reset: reset {
+ compatible = "raspberrypi,firmware-reset";
+ #reset-cells = <1>;
+ };
};
...
diff --git a/include/dt-bindings/reset/raspberrypi,firmware-reset.h b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
new file mode 100644
index 000000000000..1a4f4c792723
--- /dev/null
+++ b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne <[email protected]>
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+
+#define RASPBERRYPI_FIRMWARE_RESET_ID_USB 0
+#define RASPBERRYPI_FIRMWARE_RESET_NUM_IDS 1
+
+#endif
--
2.27.0
On 6/29/2020 9:18 AM, Nicolas Saenz Julienne wrote:
> Some atypical users of xhci-pci might need to manually reset their xHCI
> controller before starting the HCD setup. Check if a reset controller
> device is available to the PCI bus and trigger a reset.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> Acked-by: Mathias Nyman <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
Hi everyone.
On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> co-processor, VideoCore. This series reworks how we handle this.
>
> The previous solution makes use of PCI quirks and exporting platform
> specific functions. Albeit functional it feels pretty shoehorned. This
> proposes an alternative way of handling the triggering of the xHCI chip
> initialization trough means of a reset controller.
>
> The benefits are pretty evident: less platform churn in core xHCI code,
> and no explicit device dependency management in pcie-brcmstb.
>
> Note that patch #1 depends on another series[1], that was just applied
> into the clk maintainer's tree.
>
> The series is based on v5.8-rc3
>
> v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
> v2: https://lkml.org/lkml/2020/6/9/875
> v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
>
> [1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
>
> ---
We were waiting on a dependency to be merged upstream to get this. They are now
in, so could we move things forward?
I can take the device tree patches, I guess philipp can take the reset
controller code. But I'm not so sure who should be taking the PCI/USB
counterparts.
Regards,
Nicolas
>
> Changes since v4:
> - Adress Andy's comments
>
> Changes since v3:
> - Rework dt patch to include root bridge as a separate node
> - Update xhci-pci patch now that the xhci dev has a dt node (it was
> getting it in the past from its bus)
>
> Changes since v2:
> - Add reset to resume routine in xhci-pci
> - Correct of refcount in pci-quirks
> - Correct typos
> - Use include file to define firmware reset IDs
>
> Changes since v1:
> - Rework reset controller so it's less USB centric
> - Use correct reset controller API in xhci-pci
> - Correct typos
>
> Nicolas Saenz Julienne (9):
> dt-bindings: reset: Add a binding for the RPi Firmware reset
> controller
> reset: Add Raspberry Pi 4 firmware reset controller
> ARM: dts: bcm2711: Add firmware usb reset node
> ARM: dts: bcm2711: Add reset controller to xHCI node
> usb: xhci-pci: Add support for reset controllers
> Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk"
> usb: host: pci-quirks: Bypass xHCI quirks for Raspberry Pi 4
> Revert "firmware: raspberrypi: Introduce vl805 init routine"
> Revert "PCI: brcmstb: Wait for Raspberry Pi's firmware when present"
>
> .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++++
> drivers/firmware/Kconfig | 3 +-
> drivers/firmware/raspberrypi.c | 61 ---------
> drivers/pci/controller/pcie-brcmstb.c | 17 ---
> drivers/reset/Kconfig | 11 ++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-raspberrypi.c | 122 ++++++++++++++++++
> drivers/usb/host/pci-quirks.c | 22 ++--
> drivers/usb/host/xhci-pci.c | 10 ++
> drivers/usb/host/xhci.h | 2 +
> .../reset/raspberrypi,firmware-reset.h | 13 ++
> include/soc/bcm2835/raspberrypi-firmware.h | 7 -
> 13 files changed, 215 insertions(+), 97 deletions(-)
> create mode 100644 drivers/reset/reset-raspberrypi.c
> create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
>
On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:
> Hi everyone.
>
> On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
>> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
>> loaded directly from an EEPROM or, if not present, by the SoC's
>> co-processor, VideoCore. This series reworks how we handle this.
>>
>> The previous solution makes use of PCI quirks and exporting platform
>> specific functions. Albeit functional it feels pretty shoehorned. This
>> proposes an alternative way of handling the triggering of the xHCI chip
>> initialization trough means of a reset controller.
>>
>> The benefits are pretty evident: less platform churn in core xHCI code,
>> and no explicit device dependency management in pcie-brcmstb.
>>
>> Note that patch #1 depends on another series[1], that was just applied
>> into the clk maintainer's tree.
>>
>> The series is based on v5.8-rc3
>>
>> v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
>> v2: https://lkml.org/lkml/2020/6/9/875
>> v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
>>
>> [1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
>>
>> ---
>
> We were waiting on a dependency to be merged upstream to get this. They are now
> in, so could we move things forward?
>
> I can take the device tree patches, I guess philipp can take the reset
> controller code. But I'm not so sure who should be taking the PCI/USB
> counterparts.
Should we route everything through the USB tree since that is where the
changes that do require synchronization with other subsystems and DTS is
needed the most?
--
Florian
On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote:
>
>
> On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:
> > Hi everyone.
> >
> > On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
> > > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> > > loaded directly from an EEPROM or, if not present, by the SoC's
> > > co-processor, VideoCore. This series reworks how we handle this.
> > >
> > > The previous solution makes use of PCI quirks and exporting platform
> > > specific functions. Albeit functional it feels pretty shoehorned. This
> > > proposes an alternative way of handling the triggering of the xHCI chip
> > > initialization trough means of a reset controller.
> > >
> > > The benefits are pretty evident: less platform churn in core xHCI code,
> > > and no explicit device dependency management in pcie-brcmstb.
> > >
> > > Note that patch #1 depends on another series[1], that was just applied
> > > into the clk maintainer's tree.
> > >
> > > The series is based on v5.8-rc3
> > >
> > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
> > > v2: https://lkml.org/lkml/2020/6/9/875
> > > v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
> > >
> > > [1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
> > >
> > > ---
> >
> > We were waiting on a dependency to be merged upstream to get this. They are now
> > in, so could we move things forward?
> >
> > I can take the device tree patches, I guess philipp can take the reset
> > controller code. But I'm not so sure who should be taking the PCI/USB
> > counterparts.
>
> Should we route everything through the USB tree since that is where the
> changes that do require synchronization with other subsystems and DTS is
> needed the most?
> --
> Florian
That's fine with me, if everyone else is ok with it :)
On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote:
> On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote:
> >
> > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:
> > > Hi everyone.
> > >
> > > On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
> > > > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> > > > loaded directly from an EEPROM or, if not present, by the SoC's
> > > > co-processor, VideoCore. This series reworks how we handle this.
> > > >
> > > > The previous solution makes use of PCI quirks and exporting platform
> > > > specific functions. Albeit functional it feels pretty shoehorned. This
> > > > proposes an alternative way of handling the triggering of the xHCI chip
> > > > initialization trough means of a reset controller.
> > > >
> > > > The benefits are pretty evident: less platform churn in core xHCI code,
> > > > and no explicit device dependency management in pcie-brcmstb.
> > > >
> > > > Note that patch #1 depends on another series[1], that was just applied
> > > > into the clk maintainer's tree.
> > > >
> > > > The series is based on v5.8-rc3
> > > >
> > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
> > > > v2: https://lkml.org/lkml/2020/6/9/875
> > > > v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
> > > >
> > > > [1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
> > > >
> > > > ---
> > >
> > > We were waiting on a dependency to be merged upstream to get this. They are now
> > > in, so could we move things forward?
> > >
> > > I can take the device tree patches, I guess philipp can take the reset
> > > controller code. But I'm not so sure who should be taking the PCI/USB
> > > counterparts.
> >
> > Should we route everything through the USB tree since that is where the
> > changes that do require synchronization with other subsystems and DTS is
> > needed the most?
> > --
> > Florian
>
> That's fine with me, if everyone else is ok with it :)
Sounds good to me.
On Fri, Aug 14, 2020 at 12:04:05PM +0200, Nicolas Saenz Julienne wrote:
> On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote:
> > On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote:
> > >
> > > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:
> > > > Hi everyone.
> > > >
> > > > On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:
> > > > > On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> > > > > loaded directly from an EEPROM or, if not present, by the SoC's
> > > > > co-processor, VideoCore. This series reworks how we handle this.
> > > > >
> > > > > The previous solution makes use of PCI quirks and exporting platform
> > > > > specific functions. Albeit functional it feels pretty shoehorned. This
> > > > > proposes an alternative way of handling the triggering of the xHCI chip
> > > > > initialization trough means of a reset controller.
> > > > >
> > > > > The benefits are pretty evident: less platform churn in core xHCI code,
> > > > > and no explicit device dependency management in pcie-brcmstb.
> > > > >
> > > > > Note that patch #1 depends on another series[1], that was just applied
> > > > > into the clk maintainer's tree.
> > > > >
> > > > > The series is based on v5.8-rc3
> > > > >
> > > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
> > > > > v2: https://lkml.org/lkml/2020/6/9/875
> > > > > v1: https://lore.kernel.org/linux-usb/[email protected]/T/#t
> > > > >
> > > > > [1] https://lore.kernel.org/linux-clk/[email protected]/T/#t
> > > > >
> > > > > ---
> > > >
> > > > We were waiting on a dependency to be merged upstream to get this. They are now
> > > > in, so could we move things forward?
> > > >
> > > > I can take the device tree patches, I guess philipp can take the reset
> > > > controller code. But I'm not so sure who should be taking the PCI/USB
> > > > counterparts.
> > >
> > > Should we route everything through the USB tree since that is where the
> > > changes that do require synchronization with other subsystems and DTS is
> > > needed the most?
> > > --
> > > Florian
> >
> > That's fine with me, if everyone else is ok with it :)
>
> Sounds good to me.
All now queued up, thanks for sticking with this!
greg k-h