| Message ID | 20201004162908.3216898-1-martin.blumenstingl@googlemail.com |
|---|---|
| Headers | show |
| Series | GPIO support on the Etron EJ168/EJ188/EJ198 xHCI controllers | expand |
On Sun, Oct 4, 2020 at 8:00 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > Add the vendor ID for Etron Technology, Inc. as well as the device IDs > for the two USB xHCI controllers EJ168 and EJ188. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> (...) > #define PCI_VENDOR_ID_REDHAT 0x1b36 > > +#define PCI_VENDOR_ID_ETRON 0x1b6f > +#define PCI_DEVICE_ID_ETRON_EJ168 0x7023 > +#define PCI_DEVICE_ID_ETRON_EJ188 0x7052 If you're defining that here, I think it should also be removed in drivers/usb/host/xhci-pci.c by including this file instead? Yours, Linus Walleij
On Sun, Oct 4, 2020 at 8:00 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > The goal of this series to add support for the GPIO controller on the > Etron EJ168/EJ188/EJ198 controllers. This overall is a fine driver, but have you considered the option of just implementing the GPIO chip in drivers/usb/host/xhci-pci.c? There are several USB serial adapters that have a GPIO chip embedded and we just add the GPIO chip into the serial driver. I have done the same with some networking switches. It is perfectly fine for drivers outside of drivers/gpio to occasionally define a minor GPIO chip if GPIO is not their primary function. Please consider simply activating the XHCI driver and make it instantiate a GPIO chip if it happens to be an EJ168/EJ188/EJ198 controller. Yours, Linus Walleij
Hi Martin, thanks for your patch! 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. On Sun, Oct 4, 2020 at 8:00 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > EJ168/EJ188/EJ198 are USB xHCI controllers. They also contain four GPIO > lines which are used on some systems to toggle an LED based on whether a > USB device is connected. > > There is no public datasheet available for this hardware. All > information in this driver is taken from the > "F9K1115v2.03.97-GPL-10.2.85-20140313" GPL code dump of the Belkin > F9K1115v2. This board comes with an EJ168 USB xHCI controller and the > USB 3.0 LED is connected to one of the GPIOs. Inside the GPL source > archive the related code can be found in: > linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> (...) > +config GPIO_EJ1X8 > + tristate "Etron Tech Inc. EJ168/EJ188/EJ198 GPIO driver" > + depends on OF_GPIO && PCI It is fine to just select GPIOLIB if you want this to always be compiled-in (if the USB maintainers agree). > + help > + Selecting this option will enable the GPIO pins present on > + the Etron Tech Inc. EJ168/EJ188/EJ198 USB xHCI controllers. > + > + If unsure, say N. (...) > +#define EJ1X8_GPIO_INIT 0x44 > +#define EJ1X8_GPIO_WRITE 0x68 > +#define EJ1X8_GPIO_READ 0x6c > + > +#define EJ1X8_GPIO_CTRL 0x18005020 > +#define EJ1X8_GPIO_CTRL_READ_ALL_MASK GENMASK(7, 0) > +#define EJ1X8_GPIO_CTRL_WRITE_ALL_MASK GENMASK(23, 16) > +#define EJ1X8_GPIO_CTRL_OUT_LOW 0x0 > +#define EJ1X8_GPIO_CTRL_OUT_HIGH 0x1 > +#define EJ1X8_GPIO_CTRL_IN 0x2 > +#define EJ1X8_GPIO_CTRL_MASK 0x3 > + > +#define EJ1X8_GPIO_MODE 0x18005022 > +#define EJ1X8_GPIO_MODE_READ_WRITE_ALL_MASK GENMASK(23, 16) > +#define EJ1X8_GPIO_MODE_DISABLE 0x0 > +#define EJ1X8_GPIO_MODE_ENABLE 0x1 > +#define EJ1X8_GPIO_MODE_MASK 0x3 Nice that you got all of this out of reverse-engineering! > +static LIST_HEAD(ej1x8_gpios); This should not be necessary. Tie the GPIO state into the PCI device driver state, possibly using some #ifdefs. > +static u8 ej1x8_gpio_shift(unsigned int gpio, u8 mask) > +{ > + return (gpio * fls(mask)); > +} > + > +static u8 ej1x8_gpio_mask(unsigned int gpio, u8 mask) > +{ > + return mask << ej1x8_gpio_shift(gpio, mask); > +} This looks a bit like regmap but trying to use regmap for this would probably be overengineering. Looking at the code I get annoyed that it uses the config space to manipulate the GPIOs, else you could have used GPIO_GENERIC but now you can't, how typical. Other than that the code looks nice, but fold it into the USB host driver somehow unless there is a compelling argument as to why not. Yours, Linus Walleij
Hi Linus, On Wed, Oct 7, 2020 at 11:29 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > Hi Martin, > > thanks for your patch! thank you for reviewing the whole series! > 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 [...] > This should not be necessary. Tie the GPIO state into the PCI device > driver state, possibly using some #ifdefs. > > > +static u8 ej1x8_gpio_shift(unsigned int gpio, u8 mask) > > +{ > > + return (gpio * fls(mask)); > > +} > > + > > +static u8 ej1x8_gpio_mask(unsigned int gpio, u8 mask) > > +{ > > + return mask << ej1x8_gpio_shift(gpio, mask); > > +} > > This looks a bit like regmap but trying to use regmap for this > would probably be overengineering. the problem is also the "INIT" register which needs to be set before writing the registers > Looking at the code I get annoyed that it uses the config space to > manipulate the GPIOs, else you could have used GPIO_GENERIC > but now you can't, how typical. I think this won't work in practice because of the EJ1X8_GPIO_CTRL for which we have to read from bits [7:0] but write to bits [23:16] due to this (and the INIT register as mentioned above) I did not consider GPIO_GENERIC any further > Other than that the code looks nice, but fold it into the USB > host driver somehow unless there is a compelling argument > as to why not. will do so, thanks! Best regards, Martin
Hi Linus, On Wed, Oct 7, 2020 at 11:14 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Sun, Oct 4, 2020 at 8:00 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > Add the vendor ID for Etron Technology, Inc. as well as the device IDs > > for the two USB xHCI controllers EJ168 and EJ188. > > > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > (...) > > > #define PCI_VENDOR_ID_REDHAT 0x1b36 > > > > +#define PCI_VENDOR_ID_ETRON 0x1b6f > > +#define PCI_DEVICE_ID_ETRON_EJ168 0x7023 > > +#define PCI_DEVICE_ID_ETRON_EJ188 0x7052 > > If you're defining that here, I think it should also be > removed in > drivers/usb/host/xhci-pci.c > by including this file instead? you are absolutely right - I missed that part I will change this in v2 - thanks for pointing it out! Best regards, Martin
On Wed, Oct 07, 2020 at 09:45:23PM +0200, Martin Blumenstingl wrote: > Hi Linus, > > On Wed, Oct 7, 2020 at 11:14 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > > > On Sun, Oct 4, 2020 at 8:00 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > > > > Add the vendor ID for Etron Technology, Inc. as well as the device IDs > > > for the two USB xHCI controllers EJ168 and EJ188. > > > > > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > > > (...) > > > > > #define PCI_VENDOR_ID_REDHAT 0x1b36 > > > > > > +#define PCI_VENDOR_ID_ETRON 0x1b6f > > > +#define PCI_DEVICE_ID_ETRON_EJ168 0x7023 > > > +#define PCI_DEVICE_ID_ETRON_EJ188 0x7052 > > > > If you're defining that here, I think it should also be > > removed in > > drivers/usb/host/xhci-pci.c > > by including this file instead? > you are absolutely right - I missed that part > I will change this in v2 - thanks for pointing it out! And please mention the 2+ places these are used in the commit log (see the comment at the top of include/linux/pci_ids.h).
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
Hi Linus, On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > 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. next week I have some free time to work on this I am still interested in any ideas that you have about this Best regards, Martin
On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > 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. Since PCI devices have device-wide power management and things like that I think that is a really dangerous idea. What if the GPIO driver starts poking around in this PCI device when the main driver is also probed and has put the device into sleep state? This type of set-up needs to be discussed with the PCI maintainer to make sure it is safe. > 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). This sounds about right. > 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 I might be naive but should it not be the other way around? That xhci-pci-etron is dependent on xhci-pci? I imagine it would be an optional add-on. > 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. Make sure the etron part is an additional module that can be loaded after xhci-pci. OpenWrt support optional modules to be compiled per-system. Yours, Linus Walleij
Hi Linus, On Tue, Jan 5, 2021 at 11:23 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > 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. > > Since PCI devices have device-wide power management and things > like that I think that is a really dangerous idea. > > What if the GPIO driver starts poking around in this PCI device > when the main driver is also probed and has put the device > into sleep state? that is asking for trouble, indeed. [...] > > 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). > > This sounds about right. > > > 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 > > I might be naive but should it not be the other way around? > That xhci-pci-etron is dependent on xhci-pci? I imagine > it would be an optional add-on. the only way to achieve this that I can think of is to basically have xhci-pci-etron implement it's own pci_driver and then call xhci_pci_probe, xhci_pci_remove, etc. but then it depends on the driver load order if the GPIO controller is exposed what structure did you have in mind to achieve this? > > 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. > > Make sure the etron part is an additional module that can be > loaded after xhci-pci. my approach from above unfortunately would not achieve this so if you have an idea how to achieve this (or have any other driver in mind that I can use as reference, even if not related to GPIO/USB/PCI then please let me know) > OpenWrt support optional modules to be compiled per-system. that I already found out. That's why I think that I need to get the driver part "right" and then get the OpenWrt part done in just a few lines of their build-system Best regards, Martin
On Wed, Jan 6, 2021 at 4:17 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > > 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 > > > > I might be naive but should it not be the other way around? > > That xhci-pci-etron is dependent on xhci-pci? I imagine > > it would be an optional add-on. > > the only way to achieve this that I can think of is to basically have > xhci-pci-etron implement it's own pci_driver and then call > xhci_pci_probe, xhci_pci_remove, etc. > but then it depends on the driver load order if the GPIO controller is exposed > > what structure did you have in mind to achieve this? Something that is compiled and called conditionally with stubs in the local .h file. Kconfig: config FOO tristate "Main matter" config FOO_ADD_ON tristate "Optional on" depends on FOO Makefile: obj-$(CONFIG_FOO) += foo.o obj-$(CONFIG_FOO_ADD_ON) += foo-add-on.o foo.h: struct foo { ... }; #if IS_ENABLED(CONFIG_FOO_ADD_ON) int foo_add_on_init(struct foo *); #else /* No CONFIG_FOO_ADD_ON */ static int foo_add_on_init(struct foo *) { return 0; } #endif foo.c: #include "foo.h" ret = foo_add_on_init(foo); (...) foo-add-on.c: int foo_add_on_init(struct foo *) { (...) } EXPORT_SYMBOL_GPL(foo_add_on_init); > > Make sure the etron part is an additional module that can be > > loaded after xhci-pci. > > my approach from above unfortunately would not achieve this > so if you have an idea how to achieve this (or have any other driver > in mind that I can use as reference, even if not related to > GPIO/USB/PCI then please let me know) See per above. I don't see any problem with this, it will be an additional module that does not feature a probe() call and device driver bind. I think it is also possible to link both files into the same object if the optional add on is enabled, so it is part of the main module when modprobing. The foo.h stubs are still needed, then the binary will just be smaller if the add-on is not enabled. There are solutions like this in the kernel, I just don't remember one right now so grep around. Yours, Linus Walleij
Hello, I have a "Belkin F9K115v2" (wifi router) [0]. It comes with an Etron EJ168 xHCI controllers soldered to the board. One of the LEDs on this device is connected to one of the four GPIO lines provided by the Etron xHCI controller. The goal of this series to add support for the GPIO controller on the Etron EJ168/EJ188/EJ198 controllers. Unfortunately there's no (public) datasheet available. I have Cc'ed Etron and I'm hoping that they can either provide a datasheet or at least some code-review feedback. Instead I used the GPL tarball [0] for this device. Inside this tarball the relevant "reference" code is in: linux/kernels/mips-linux-2.6.31/drivers/usb/host/etxhci-pci.c Unfortunately it uses magic numbers for the registers instead of human-readable names. The register names are what I came up with. For reference, I have tested this on a patched OpenWrt build with the following .dts changes (I am showing these here so it will be easier to review the whole series): &pcie1 { status = "okay"; xhci: usb-controller@0,0,0 { compatible = "pci1b6f,7023"; reg = <0x0 0x0 0x0 0x0 0x1000>; #address-cells = <1>; #size-cells = <0>; gpio-controller; #gpio-cells = <2>; xhci_port0: port@1 { reg = <1>; #trigger-source-cells = <0>; }; }; }; leds { compatible = "gpio-leds"; usb3 { label = "green:usb3"; gpios = <&xhci 2 GPIO_ACTIVE_LOW>; trigger-sources = <&xhci_port0>; linux,default-trigger = "usbport"; }; }; In general I followed [2] because it says: PCI drivers should have a really good reason for not using the pci_register_driver() [...] The main reason [...] is because one PCI device implements several different HW services. My understanding that my driver fits into this category. I am sending this as RFC because this is my first self-written GPIO driver as well as my first PCI device driver. Any feedback is welcome! Best regards, Martin [0] https://openwrt.org/toh/belkin/f9k1115v2 [1] https://www.belkin.com/support/dl/F9K1115v2.03.97-GPL-10.2.85.tar.gz [2] https://www.kernel.org/doc/html/latest/PCI/pci.html#how-to-find-pci-devices-manually Martin Blumenstingl (3): PCI: Add the IDs for Etron EJ168 and EJ188 dt-bindings: gpio: Add binding documentation for Etron EJ168/EJ188/EJ198 gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198 .../devicetree/bindings/gpio/etron,ej1x8.yaml | 48 +++ drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-ej1x8.c | 311 ++++++++++++++++++ include/linux/pci_ids.h | 4 + 5 files changed, 373 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/etron,ej1x8.yaml create mode 100644 drivers/gpio/gpio-ej1x8.c