This series attempts to add support for software nodes to gpiolib, using software node references that were introduced recently. This allows us to convert more drivers to the generic device properties and drop support for custom platform data:
static const struct software_node gpio_bank_b_node = { |-------.name = "B", };
static const struct property_entry simone_key_enter_props[] = { |-------PROPERTY_ENTRY_U32("linux,code", KEY_ENTER), |-------PROPERTY_ENTRY_STRING("label", "enter"), |-------PROPERTY_ENTRY_REF("gpios", &gpio_bank_b_node, 123, GPIO_ACTIVE_LOW), |-------{ } };
If we agree in principle, I would like to have the very first 3 patches in an immutable branch off maybe -rc8 so that it can be pulled into individual subsystems so that patches switching various drivers to fwnode_gpiod_get_index() could be applied.
Thanks, Dmitry
Dmitry Torokhov (11): gpiolib: of: add a fallback for wlf,reset GPIO name gpiolib: introduce devm_fwnode_gpiod_get_index() gpiolib: introduce fwnode_gpiod_get_index() net: phylink: switch to using fwnode_gpiod_get_index() net: mdio: switch to using fwnode_gpiod_get_index() drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index() gpliolib: make fwnode_get_named_gpiod() static gpiolib: of: tease apart of_find_gpio() gpiolib: of: tease apart acpi_find_gpio() gpiolib: consolidate fwnode GPIO lookups gpiolib: add support for software nodes
drivers/gpio/Makefile | 1 + drivers/gpio/gpiolib-acpi.c | 153 ++++++++++++++---------- drivers/gpio/gpiolib-acpi.h | 21 ++-- drivers/gpio/gpiolib-devres.c | 33 ++---- drivers/gpio/gpiolib-of.c | 159 ++++++++++++++----------- drivers/gpio/gpiolib-of.h | 26 ++-- drivers/gpio/gpiolib-swnode.c | 92 +++++++++++++++ drivers/gpio/gpiolib-swnode.h | 13 ++ drivers/gpio/gpiolib.c | 184 ++++++++++++++++------------- drivers/gpu/drm/bridge/ti-tfp410.c | 4 +- drivers/net/phy/mdio_bus.c | 4 +- drivers/net/phy/phylink.c | 4 +- include/linux/gpio/consumer.h | 53 ++++++--- 13 files changed, 471 insertions(+), 276 deletions(-) create mode 100644 drivers/gpio/gpiolib-swnode.c create mode 100644 drivers/gpio/gpiolib-swnode.h
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com ---
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index 61cc2354ef1b..d9c9c9ebad2b 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c +++ b/drivers/gpu/drm/bridge/ti-tfp410.c @@ -284,8 +284,8 @@ static int tfp410_get_connector_properties(struct tfp410 *dvi) else dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
- dvi->hpd = fwnode_get_named_gpiod(&connector_node->fwnode, - "hpd-gpios", 0, GPIOD_IN, "hpd"); + dvi->hpd = fwnode_gpiod_get_index(&connector_node->fwnode, + "hpd", 0, GPIOD_IN, "hpd"); if (IS_ERR(dvi->hpd)) { ret = PTR_ERR(dvi->hpd); dvi->hpd = NULL;
Hi Dmitry,
(CC'ing Heikki as the original author of software nodes support)
Thank you for the patch.
On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote:
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
s/bit/but/
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
On a side note, as I'm not very familiar with software nodes, I tried to see how they are to be used, and it seems they are completely undocumented :-( Heikki, is this something that could be fixed ?
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index 61cc2354ef1b..d9c9c9ebad2b 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c +++ b/drivers/gpu/drm/bridge/ti-tfp410.c @@ -284,8 +284,8 @@ static int tfp410_get_connector_properties(struct tfp410 *dvi) else dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
- dvi->hpd = fwnode_get_named_gpiod(&connector_node->fwnode,
"hpd-gpios", 0, GPIOD_IN, "hpd");
- dvi->hpd = fwnode_gpiod_get_index(&connector_node->fwnode,
"hpd", 0, GPIOD_IN, "hpd");
On Sat, Sep 21, 2019 at 02:12:28AM +0300, Laurent Pinchart wrote:
Hi Dmitry,
(CC'ing Heikki as the original author of software nodes support)
Thank you for the patch.
On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote:
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
s/bit/but/
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
On a side note, as I'm not very familiar with software nodes, I tried to see how they are to be used, and it seems they are completely undocumented :-( Heikki, is this something that could be fixed ?
OK. I'll start writing API documentation for it.
thanks,
Hi Heikki,
On Mon, Sep 23, 2019 at 06:03:33PM +0300, Heikki Krogerus wrote:
On Sat, Sep 21, 2019 at 02:12:28AM +0300, Laurent Pinchart wrote:
Hi Dmitry,
(CC'ing Heikki as the original author of software nodes support)
Thank you for the patch.
On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote:
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
s/bit/but/
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
On a side note, as I'm not very familiar with software nodes, I tried to see how they are to be used, and it seems they are completely undocumented :-( Heikki, is this something that could be fixed ?
OK. I'll start writing API documentation for it.
That's great, thanks ! I'll do my best to review it if you CC me.
On Wed, Sep 11, 2019 at 12:52:04AM -0700, Dmitry Torokhov wrote:
This series attempts to add support for software nodes to gpiolib, using software node references that were introduced recently. This allows us to convert more drivers to the generic device properties and drop support for custom platform data:
static const struct software_node gpio_bank_b_node = { |-------.name = "B", };
static const struct property_entry simone_key_enter_props[] = { |-------PROPERTY_ENTRY_U32("linux,code", KEY_ENTER), |-------PROPERTY_ENTRY_STRING("label", "enter"), |-------PROPERTY_ENTRY_REF("gpios", &gpio_bank_b_node, 123, GPIO_ACTIVE_LOW), |-------{ } };
If we agree in principle, I would like to have the very first 3 patches in an immutable branch off maybe -rc8 so that it can be pulled into individual subsystems so that patches switching various drivers to fwnode_gpiod_get_index() could be applied.
FWIW, Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
for patches 1-8 after addressing minor issues. I'll review the rest later on.
Thanks, Dmitry
Dmitry Torokhov (11): gpiolib: of: add a fallback for wlf,reset GPIO name gpiolib: introduce devm_fwnode_gpiod_get_index() gpiolib: introduce fwnode_gpiod_get_index() net: phylink: switch to using fwnode_gpiod_get_index() net: mdio: switch to using fwnode_gpiod_get_index() drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index() gpliolib: make fwnode_get_named_gpiod() static gpiolib: of: tease apart of_find_gpio() gpiolib: of: tease apart acpi_find_gpio() gpiolib: consolidate fwnode GPIO lookups gpiolib: add support for software nodes
drivers/gpio/Makefile | 1 + drivers/gpio/gpiolib-acpi.c | 153 ++++++++++++++---------- drivers/gpio/gpiolib-acpi.h | 21 ++-- drivers/gpio/gpiolib-devres.c | 33 ++---- drivers/gpio/gpiolib-of.c | 159 ++++++++++++++----------- drivers/gpio/gpiolib-of.h | 26 ++-- drivers/gpio/gpiolib-swnode.c | 92 +++++++++++++++ drivers/gpio/gpiolib-swnode.h | 13 ++ drivers/gpio/gpiolib.c | 184 ++++++++++++++++------------- drivers/gpu/drm/bridge/ti-tfp410.c | 4 +- drivers/net/phy/mdio_bus.c | 4 +- drivers/net/phy/phylink.c | 4 +- include/linux/gpio/consumer.h | 53 ++++++--- 13 files changed, 471 insertions(+), 276 deletions(-) create mode 100644 drivers/gpio/gpiolib-swnode.c create mode 100644 drivers/gpio/gpiolib-swnode.h
-- 2.23.0.162.g0b9fbb3734-goog
On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
If we agree in principle, I would like to have the very first 3 patches in an immutable branch off maybe -rc8 so that it can be pulled into individual subsystems so that patches switching various drivers to fwnode_gpiod_get_index() could be applied.
I think it seems a bit enthusiastic to have non-GPIO subsystems pick up these changes this close to the merge window so my plan is to merge patches 1.2.3 (1 already merged) and then you could massage the other subsystems in v5.4-rc1.
But if other subsystems say "hey we want do fix this in like 3 days" then I'm game for an immutable branch as well.
Yours, Linus Walleij
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
If we agree in principle, I would like to have the very first 3 patches in an immutable branch off maybe -rc8 so that it can be pulled into individual subsystems so that patches switching various drivers to fwnode_gpiod_get_index() could be applied.
I think it seems a bit enthusiastic to have non-GPIO subsystems pick up these changes this close to the merge window so my plan is to merge patches 1.2.3 (1 already merged) and then you could massage the other subsystems in v5.4-rc1.
But if other subsystems say "hey we want do fix this in like 3 days" then I'm game for an immutable branch as well.
No, if it is still has a chance for -rc1 then I'm good. I was thinking if it does not go into -rc1 I could convince some of them merge a targeted immutable branch off -rc8 or 5.3 final and then apply patches relevant to their subsystems so we do not have to wait till 5.6 to land everything.
Thanks.
Hi Linus,
On Mon, Sep 16, 2019 at 05:22:07PM -0700, Dmitry Torokhov wrote:
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
If we agree in principle, I would like to have the very first 3 patches in an immutable branch off maybe -rc8 so that it can be pulled into individual subsystems so that patches switching various drivers to fwnode_gpiod_get_index() could be applied.
I think it seems a bit enthusiastic to have non-GPIO subsystems pick up these changes this close to the merge window so my plan is to merge patches 1.2.3 (1 already merged) and then you could massage the other subsystems in v5.4-rc1.
But if other subsystems say "hey we want do fix this in like 3 days" then I'm game for an immutable branch as well.
No, if it is still has a chance for -rc1 then I'm good. I was thinking if it does not go into -rc1 I could convince some of them merge a targeted immutable branch off -rc8 or 5.3 final and then apply patches relevant to their subsystems so we do not have to wait till 5.6 to land everything.
So I guess we missed -rc1. Any chance we could get an immutable branch off -rc1 that you will pull into your main branch and I hopefully can persuade other maintainers to pull as well so we do not need to drag it over 2+ merge windows?
Thanks.
On Tue, Oct 1, 2019 at 12:45 AM Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
So I guess we missed -rc1. Any chance we could get an immutable branch off -rc1 that you will pull into your main branch and I hopefully can persuade other maintainers to pull as well so we do not need to drag it over 2+ merge windows?
Yes I'm sorry. I was swamped with stabilizing the kernel. I made an immutable branch and tried to use zeroday for testing but it timed out so I folded it in for-next anyways after som basic tests.
Yours, Linus Walleij
dri-devel@lists.freedesktop.org
-
Andy Shevchenko -
Dmitry Torokhov -
Heikki Krogerus -
Laurent Pinchart -
Linus Walleij