Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201004162908.3216898-1-martin.blumenstingl@googlemail.com>
 <20201004162908.3216898-4-martin.blumenstingl@googlemail.com>
 <CACRpkdZo-U_cAhbKb4E+d+p+5FenXkGYW0RXxyk4M5uyEPCpzw@mail.gmail.com> <CAFBinCCLubmDvxfabQHx2-ucgAsm1NArMUrtPx-UA2nX5xoFFA@mail.gmail.com>
In-Reply-To: <CAFBinCCLubmDvxfabQHx2-ucgAsm1NArMUrtPx-UA2nX5xoFFA@mail.gmail.com>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Mon, 21 Dec 2020 16:28:39 +0100
Message-ID: <CAFBinCAZXJ2=fTQuAUyW1hNeJDHY3_pxo4UhxUaOZC=i1bpFxw@mail.gmail.com>
Subject: Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     linux-usb <linux-usb@vger.kernel.org>,
        linux-pci <linux-pci@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Linus,

On Wed, Oct 7, 2020 at 9:44 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
[...]
> > As noted on the earlier patches I think this should be folded into the
> > existing XHCI USB driver in drivers/usb/host/xhci-pci.c or, if that
> > gets messy, as a separate bolt-on, something like
> > xhci-pci-gpio.[c|h] in the drivers/usb/host/* directory.
> > You can use a Kconfig symbol for the GPIO portions or not.
> OK, I will do that if there are no objections from other developers
> I am intending to place the relevant code in xhci-pci-etron.c, similar
> to what we already have with xhci-pci-renesas.c
I tried this and unfortunately there's a catch.
the nice thing about having a separate GPIO driver means that the
xhci-pci driver doesn't need to know about it.

I implemented xhci-pci-etron.c and gave it a Kconfig option.
xhci-pci is then calling into xhci-pci-etron (through some
etron_xhci_pci_probe function).
unfortunately this means that xhci-pci now depends on xhci-pci-etron.
for xhci-pci-renesas this is fine (I think) because that part of the
code is needed to get the xHCI controller going
but for xhci-pci-etron this is a different story: the GPIO controller
is entirely optional and only used on few devices

my goal is (at some point in the future) to have the GPIO driver in OpenWrt.
I am not sure if they would accept a patch where xhci-pci would then
pull in the dependencies for that Etron controller, even though most
boards don't need it.

Please let me know if you have any idea on how to solve this.


Best regards,
Martin