Thread (23 messages) 23 messages, 5 authors, 2021-01-07

Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198

From: Linus Walleij <hidden>
Date: 2021-01-07 10:37:51
Also in: linux-gpio, linux-pci, linux-usb, lkml

On Wed, Jan 6, 2021 at 4:17 PM Martin Blumenstingl
[off-list ref] wrote:
quoted
quoted
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);
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help