gpio: mmio: Make driver agnostic

PATCH In review Andy Shevchenko 4 participants 27 messages Oct 25, 2023 – Dec 18, 2023 1 message not in the archive

Subsystems (4)

ACPI GPIO Driver core Software nodes and device properties

lore

Share & tools

lore

Andy Shevchenko

author reviewer

2023-10-25 18:50 UTC #0 lore raw

cover gpio: mmio: Make driver agnostic

Driver uses so far some OF APIs when generic fwnode ones can be used. Replace these APIs accordingly. Note, this will help to clean up OF headers even more.

Andy Shevchenko (3):
device property: Implement device_is_big_endian()
gpio: mmio: Make use of device properties
gpio: mmio: Clean up headers

 drivers/gpio/gpio-mmio.c | 53 +++++++++++++++-------------------------
 include/linux/property.h | 26 ++++++++++++++++++++
 2 files changed, 46 insertions(+), 33 deletions(-)

Signature · 1 line

2.40.0.1.gaa8946217a0b

Andy Shevchenko

author reviewer

2023-10-25 18:43 UTC #1 lore raw

PATCH 1/3 device property: Implement device_is_big_endian()

Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.

Provide inline helper for the users.

Signed-off-by Andy Shevchenko <[email protected]>

---
 include/linux/property.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

include/linux/property.h +26 -0

index 2b8f07fc68a9..d1400a477b0a 100644
@@ -80,12 +80,38 @@ int fwnode_property_match_string(const struct fwnode_handle *fwnode,
 
 bool fwnode_device_is_available(const struct fwnode_handle *fwnode);
 
+static inline bool fwnode_device_is_big_endian(const struct fwnode_handle *fwnode)
+{
+	if (fwnode_property_present(fwnode, "big-endian"))
+		return true;
+	if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN) &&
+	    fwnode_property_present(fwnode, "native-endian"))
+		return true;
+	return false;
+}
+
 static inline
 bool fwnode_device_is_compatible(const struct fwnode_handle *fwnode, const char *compat)
 {
 	return fwnode_property_match_string(fwnode, "compatible", compat) >= 0;
 }
 
+/**
+ * device_is_big_endian - check if a device has BE registers
+ * @dev: Pointer to the struct device
+ *
+ * Returns: true if the device has a "big-endian" property, or if the kernel
+ * was compiled for BE *and* the device has a "native-endian" property.
+ * Returns false otherwise.
+ *
+ * Callers would nominally use ioread32be/iowrite32be if
+ * device_is_big_endian() == true, or readl/writel otherwise.
+ */
+static inline bool device_is_big_endian(const struct device *dev)
+{
+	return fwnode_device_is_big_endian(dev_fwnode(dev));
+}
+
 /**
  * device_is_compatible - match 'compatible' property of the device with a given string
  * @dev: Pointer to the struct device

Signature · 1 line

2.40.0.1.gaa8946217a0b

Greg Kroah-Hartman

maintainer Acked-by on v1 1/3

2023-10-26 05:25 UTC #2 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 11 lines · Andy Shevchenko

Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Signed-off-by Andy Shevchenko <[email protected]>
---
 include/linux/property.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

Acked-by Greg Kroah-Hartman <[email protected]>

Andy Shevchenko

author reviewer

2023-10-26 12:27 UTC #3 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 9 lines · Greg Kroah-Hartman

Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>

Thank you, Greg.

Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

author reviewer

2023-11-02 15:33 UTC #4 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 9 lines · Andy Shevchenko

Quoted 8 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.

Quoted 7 lines

Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).

Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Greg Kroah-Hartman

maintainer

2023-11-02 15:58 UTC #5 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 14 lines · Andy Shevchenko

Quoted 13 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.

Quoted 8 lines

Quoted 3 lines
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

After -rc1 is out, I'll look into it, can't do anything until then, sorry...

greg k-h

Andy Shevchenko

author reviewer

2023-11-02 16:47 UTC #6 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 19 lines · Greg Kroah-Hartman

Quoted 18 lines · Andy Shevchenko
Quoted 16 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).

Quoted 7 lines

Quoted 4 lines
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
After -rc1 is out, I'll look into it, can't do anything until then, sorry...

No problem, this is actually a great news!

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Bartosz Golaszewski

2023-11-03 09:09 UTC #7 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

In reply to Andy Shevchenko

Quoted 15 lines · Andy Shevchenko

Quoted 13 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.

Quoted 9 lines

Quoted 3 lines
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.

Bart

Bartosz Golaszewski

2023-11-15 14:59 UTC #8 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 28 lines · Bartosz Golaszewski

Quoted 15 lines · Andy Shevchenko
Quoted 13 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Quoted 9 lines
Quoted 3 lines
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

Quoted 4 lines

It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Bart

Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?

Bart

Greg Kroah-Hartman

maintainer

2023-11-15 20:23 UTC #9 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 29 lines · Bartosz Golaszewski

Quoted 28 lines · Bartosz Golaszewski
Quoted 24 lines · Andy Shevchenko
Quoted 9 lines · Andy Shevchenko
Quoted 8 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

Quoted 7 lines

Quoted 4 lines
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Bart
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?

Sure, let me catch up with patches after I return from Plumbers next week.

greg k-h

Andy Shevchenko

author reviewer

2023-12-07 14:20 UTC #10 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 27 lines · Greg Kroah-Hartman

Quoted 26 lines · Bartosz Golaszewski
Quoted 25 lines · Bartosz Golaszewski
Quoted 22 lines · Andy Shevchenko
Quoted 9 lines · Andy Shevchenko
Quoted 8 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.

Hope Plumbers went well!

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Greg Kroah-Hartman

maintainer

2023-12-15 14:49 UTC #11 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 31 lines · Andy Shevchenko

Quoted 30 lines · Greg Kroah-Hartman
Quoted 29 lines · Bartosz Golaszewski
Quoted 27 lines · Bartosz Golaszewski
Quoted 14 lines · Andy Shevchenko
Quoted 13 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 6 lines · Andy Shevchenko
Some users want to use the struct device pointer to see if the device is big endian in terms of Open Firmware specifications, i.e. if it has a "big-endian" property, or if the kernel was compiled for BE *and* the device has a "native-endian" property.
Provide inline helper for the users.
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Quoted 8 lines
Quoted 3 lines
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!

Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.

thanks,

greg k-h

Andy Shevchenko

author reviewer

2023-12-15 15:11 UTC #12 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 9 lines · Greg Kroah-Hartman

Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:

...

Quoted 19 lines

Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Quoted 7 lines
Quoted 4 lines
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.

No problem and thank you!

Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Bartosz Golaszewski

2023-12-18 10:35 UTC #13 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 38 lines · Andy Shevchenko

Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:
...
Quoted 24 lines
Quoted 23 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!

Quoted 9 lines

Quoted 3 lines
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.
No problem and thank you!
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?

Ugh, this is rebased on top of 6.7-rc3...

My tree is based on rc1, if I pull it, then it'll be a mess.

Andy: How badly do you want it in v6.8? Can this wait until after the merge window?

Bart

Quoted 5 lines

--
With Best Regards,
Andy Shevchenko

Andy Shevchenko

author reviewer

2023-12-18 10:56 UTC #14 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 12 lines · Bartosz Golaszewski

Quoted 10 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:

...

Quoted 28 lines

Quoted 28 lines
Quoted 27 lines
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Quoted 8 lines
Quoted 3 lines
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.

Quoted 8 lines

Quoted 4 lines
No problem and thank you!
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.

But v6.7-rc3 is something that is already in the upstream. I don't see how it can be more "mess" with this. Whatever...

Quoted 2 lines

Andy: How badly do you want it in v6.8? Can this wait until after the merge window?

I waited for a cycle already with this...

OTOH GPIO part is not anyhow critical from the semantic point of view. Since the main patch is in Greg's tree I'll survive with GPIO stuff going next cycle.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Bartosz Golaszewski

2023-12-18 11:06 UTC #15 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 50 lines · Andy Shevchenko

Quoted 12 lines · Bartosz Golaszewski
Quoted 10 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:
...
Quoted 33 lines
Quoted 32 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Quoted 7 lines
Quoted 4 lines
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.
No problem and thank you!
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?

Quoted 7 lines

Quoted 3 lines
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.
But v6.7-rc3 is something that is already in the upstream. I don't see how it can be more "mess" with this. Whatever...

My for-next branch is based on v6.7-rc1 (as it should IIUC) and if I now pull Greg's tag, I will be sending rc1-rc3 stuff to Linus Torvalds in addition to the GPIO changes for v6.8. I bet he will not appreciate it.

Greg: Is it too late to have this rebased on top of v6.7-rc1 instead?

Bartosz

Quoted 14 lines

Quoted 2 lines
Andy: How badly do you want it in v6.8? Can this wait until after the merge window?
I waited for a cycle already with this...
OTOH GPIO part is not anyhow critical from the semantic point of view. Since the main patch is in Greg's tree I'll survive with GPIO stuff going next cycle.
--
With Best Regards,
Andy Shevchenko

Greg Kroah-Hartman

maintainer

2023-12-18 11:18 UTC #16 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 56 lines · Bartosz Golaszewski

Quoted 54 lines · Andy Shevchenko
Quoted 12 lines · Bartosz Golaszewski
Quoted 10 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:
...
Quoted 36 lines
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Quoted 8 lines
Quoted 3 lines
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.
No problem and thank you!
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.

Quoted 8 lines

Quoted 3 lines
But v6.7-rc3 is something that is already in the upstream. I don't see how it can be more "mess" with this. Whatever...
My for-next branch is based on v6.7-rc1 (as it should IIUC) and if I now pull Greg's tag, I will be sending rc1-rc3 stuff to Linus Torvalds in addition to the GPIO changes for v6.8. I bet he will not appreciate it.

No, you will not be sending him -rc1-rc3 stuff at all, that's not how git works.

Try it yourself and see. Git does a "what's the changesets that are in this pull request and not already in mine" when determining this. You can see it when doing a 'git request-pull', it will only show you the diff of what will be sent.

Also look at the 'git merge-base' output, it will show the point where things will start to be sent, and that will not have all of the -rc1 through -rc3 changes in it.

Quoted 1 line

Greg: Is it too late to have this rebased on top of v6.7-rc1 instead?

Sorry, but yes. But don't worry, again, git can handle all of this easily! Try it locally and see. Don't fear the 'fast-forward' :)

thanks,

greg k-h

Bartosz Golaszewski

2023-12-18 12:38 UTC #17 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 75 lines · Greg Kroah-Hartman

Quoted 56 lines · Bartosz Golaszewski
Quoted 54 lines · Andy Shevchenko
Quoted 12 lines · Bartosz Golaszewski
Quoted 10 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:
...
Quoted 36 lines
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 7 lines
Quoted 1 line
Acked-by: Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Quoted 8 lines
Quoted 3 lines
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.
No problem and thank you!
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.
Quoted 8 lines
Quoted 3 lines
But v6.7-rc3 is something that is already in the upstream. I don't see how it can be more "mess" with this. Whatever...
My for-next branch is based on v6.7-rc1 (as it should IIUC) and if I now pull Greg's tag, I will be sending rc1-rc3 stuff to Linus Torvalds in addition to the GPIO changes for v6.8. I bet he will not appreciate it.
No, you will not be sending him -rc1-rc3 stuff at all, that's not how git works.
Try it yourself and see. Git does a "what's the changesets that are in this pull request and not already in mine" when determining this. You can see it when doing a 'git request-pull', it will only show you the diff of what will be sent.

Quoted 9 lines

Also look at the 'git merge-base' output, it will show the point where things will start to be sent, and that will not have all of the -rc1 through -rc3 changes in it.
Quoted 1 line
Greg: Is it too late to have this rebased on top of v6.7-rc1 instead?
Sorry, but yes. But don't worry, again, git can handle all of this easily! Try it locally and see. Don't fear the 'fast-forward' :)

Sorry for the noise. I did try it locally and noticed that a bunch of commits that were merged before rc3 moved "before it" in git log and figured this is what the PR would look like. However the PR is correct and I should have generated it before sending the email.

Thanks for a lesson in git.
Bartosz

Quoted 4 lines

thanks,
greg k-h

Andy Shevchenko

author reviewer

2023-12-18 13:40 UTC #18 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Quoted 8 lines · Bartosz Golaszewski

Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Bartosz Golaszewski
On Fri, Dec 15, 2023 at 4:11 PM Andy Shevchenko
<[email protected]> wrote:

...

Quoted 26 lines

Quoted 26 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.
But v6.7-rc3 is something that is already in the upstream. I don't see how it can be more "mess" with this. Whatever...
My for-next branch is based on v6.7-rc1 (as it should IIUC) and if I now pull Greg's tag, I will be sending rc1-rc3 stuff to Linus Torvalds in addition to the GPIO changes for v6.8. I bet he will not appreciate it.
No, you will not be sending him -rc1-rc3 stuff at all, that's not how git works.
Try it yourself and see. Git does a "what's the changesets that are in this pull request and not already in mine" when determining this. You can see it when doing a 'git request-pull', it will only show you the diff of what will be sent.
Also look at the 'git merge-base' output, it will show the point where things will start to be sent, and that will not have all of the -rc1 through -rc3 changes in it.
Quoted 1 line
Greg: Is it too late to have this rebased on top of v6.7-rc1 instead?

Quoted 7 lines

Quoted 2 lines
Sorry, but yes. But don't worry, again, git can handle all of this easily! Try it locally and see. Don't fear the 'fast-forward' :)
Sorry for the noise. I did try it locally and noticed that a bunch of commits that were merged before rc3 moved "before it" in git log and figured this is what the PR would look like. However the PR is correct and I should have generated it before sending the email.

Right.

What Linus can rant on is when one rebases his stuff on newer rcX, the merges on contrary are pretty much okay as long as they are justified.

Quoted 1 line

Thanks for a lesson in git.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Greg Kroah-Hartman

maintainer

2023-12-18 11:08 UTC #19 lore raw

Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

In reply to Bartosz Golaszewski

Quoted 46 lines · Bartosz Golaszewski

Quoted 44 lines · Andy Shevchenko
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Bartosz Golaszewski
Quoted 5 lines · Bartosz Golaszewski
Quoted 3 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Greg Kroah-Hartman
On Wed, Oct 25, 2023 at 09:42:57PM +0300, Andy Shevchenko wrote:
...
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
Acked-by Greg Kroah-Hartman <[email protected]>
Thank you, Greg.
Bart, would it be still possible to take this into next?
I would like to have at least this patch applied (with the first user) to allow conversion of others (I have some more users of new API).
Quoted 7 lines
Quoted 4 lines
Okay, seems we missed v6.7 with this, can you then prepare an immutable branch / tag with this, so other maintainers can pull in case it's needed? (I have something against tty already and perhaps something else, let's
see.)
It arrived too late in the cycle, I needed to send my PR earlier this time as I was OoO this week.
Greg, will you take this patch through your tree and provide me with an immutable tag for this cycle?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Sure, let me catch up with patches after I return from Plumbers next week.
Hope Plumbers went well!
Sorry for the delay, immutable tag can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git device_is_big_endian-6.8-rc1
for anyone to pull from now.
No problem and thank you!

Quoted 7 lines

Quoted 3 lines
Bart, can you pull that? Or should I to my tree and then push with other GPIO patches?
Ugh, this is rebased on top of 6.7-rc3...
My tree is based on rc1, if I pull it, then it'll be a mess.

What would make it a "mess"? It's all upstream already, taking a merge from a point further in time will work just fine, git is nice :)

thanks,

greg k-h

Andy Shevchenko

author reviewer

2023-10-25 18:43 UTC #20 lore raw

PATCH 2/3 gpio: mmio: Make use of device properties

In reply to Andy Shevchenko

Convert the module to be property provider agnostic and allow it to be used on non-OF platforms.

Signed-off-by Andy Shevchenko <[email protected]>

---
 drivers/gpio/gpio-mmio.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

drivers/gpio/gpio-mmio.c +7 ~~-18~~

index 3ff0ea1e351c..66308b165a0d 100644
@@ -58,7 +58,6 @@ o        `                     ~~~~\___/~~~~    ` controller in FPGA is ,.`
 #include <linux/platform_device.h>
 #include <linux/property.h>
 #include <linux/mod_devicetable.h>
-#include <linux/of.h>
 
 #include "gpiolib.h"

@@ -688,7 +687,6 @@ static void __iomem *bgpio_map(struct platform_device *pdev,
 	return devm_ioremap_resource(&pdev->dev, r);
 }
 
-#ifdef CONFIG_OF
 static const struct of_device_id bgpio_of_match[] = {
 	{ .compatible = "brcm,bcm6345-gpio" },
 	{ .compatible = "wd,mbl-gpio" },

@@ -697,36 +695,27 @@ static const struct of_device_id bgpio_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, bgpio_of_match);
 
-static struct bgpio_pdata *bgpio_parse_dt(struct platform_device *pdev,
-					  unsigned long *flags)
+static struct bgpio_pdata *bgpio_parse_fw(struct device *dev, unsigned long *flags)
 {
 	struct bgpio_pdata *pdata;
 
-	if (!pdev->dev.of_node)
+	if (!dev_fwnode(dev))
 		return NULL;
 
-	pdata = devm_kzalloc(&pdev->dev, sizeof(struct bgpio_pdata),
-			     GFP_KERNEL);
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
 	if (!pdata)
 		return ERR_PTR(-ENOMEM);
 
 	pdata->base = -1;
 
-	if (of_device_is_big_endian(pdev->dev.of_node))
+	if (device_is_big_endian(dev))
 		*flags |= BGPIOF_BIG_ENDIAN_BYTE_ORDER;
 
-	if (of_property_read_bool(pdev->dev.of_node, "no-output"))
+	if (device_property_read_bool(dev, "no-output"))
 		*flags |= BGPIOF_NO_OUTPUT;
 
 	return pdata;
 }
-#else
-static struct bgpio_pdata *bgpio_parse_dt(struct platform_device *pdev,
-					  unsigned long *flags)
-{
-	return NULL;
-}
-#endif /* CONFIG_OF */
 
 static int bgpio_pdev_probe(struct platform_device *pdev)
 {

@@ -743,7 +732,7 @@ static int bgpio_pdev_probe(struct platform_device *pdev)
 	struct gpio_chip *gc;
 	struct bgpio_pdata *pdata;
 
-	pdata = bgpio_parse_dt(pdev, &flags);
+	pdata = bgpio_parse_fw(dev, &flags);
 	if (IS_ERR(pdata))
 		return PTR_ERR(pdata);

@@ -814,7 +803,7 @@ MODULE_DEVICE_TABLE(platform, bgpio_id_table);
 static struct platform_driver bgpio_driver = {
 	.driver = {
 		.name = "basic-mmio-gpio",
-		.of_match_table = of_match_ptr(bgpio_of_match),
+		.of_match_table = bgpio_of_match,
 	},
 	.id_table = bgpio_id_table,
 	.probe = bgpio_pdev_probe,

Signature · 1 line

2.40.0.1.gaa8946217a0b

Andy Shevchenko

author reviewer

2023-10-25 18:50 UTC #21 lore raw

PATCH 3/3 gpio: mmio: Clean up headers

In reply to Andy Shevchenko

There is a few things done:
- include only the headers we are direct user of
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically

Signed-off-by Andy Shevchenko <[email protected]>

---
 drivers/gpio/gpio-mmio.c | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

drivers/gpio/gpio-mmio.c +13 ~~-15~~

index 66308b165a0d..71e1af7c2184 100644
@@ -40,24 +40,22 @@ o        `                     ~~~~\___/~~~~    ` controller in FPGA is ,.`
  *               `.......````.```
  */
 
-#include <linux/init.h>
-#include <linux/err.h>
-#include <linux/bug.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/spinlock.h>
-#include <linux/compiler.h>
-#include <linux/types.h>
-#include <linux/errno.h>
-#include <linux/log2.h>
-#include <linux/ioport.h>
-#include <linux/io.h>
-#include <linux/gpio/driver.h>
-#include <linux/slab.h>
 #include <linux/bitops.h>
+#include <linux/compiler.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/log2.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/property.h>
-#include <linux/mod_devicetable.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#include <linux/gpio/driver.h>
 
 #include "gpiolib.h"

Signature · 1 line

2.40.0.1.gaa8946217a0b

Linus Walleij

Reviewed-by on the v1 series

2023-10-25 19:55 UTC #22 lore raw

In reply to Andy Shevchenko

Quoted 3 lines · Andy Shevchenko

Driver uses so far some OF APIs when generic fwnode ones can be used. Replace these APIs accordingly. Note, this will help to clean up OF headers even more.

Clean, elegant and does exactly what we want.

Reviewed-by Linus Walleij <[email protected]>

Yours,
Linus Walleij

Bartosz Golaszewski

2023-12-18 12:43 UTC #23 lore raw

In reply to Andy Shevchenko

Quoted 10 lines · Andy Shevchenko

Driver uses so far some OF APIs when generic fwnode ones can be used. Replace these APIs accordingly. Note, this will help to clean up OF headers even more.
Andy Shevchenko (3):
device property: Implement device_is_big_endian()
gpio: mmio: Make use of device properties
gpio: mmio: Clean up headers

Quoted 7 lines

 drivers/gpio/gpio-mmio.c | 53 +++++++++++++++-------------------------
 include/linux/property.h | 26 ++++++++++++++++++++
 2 files changed, 46 insertions(+), 33 deletions(-)

--
2.40.0.1.gaa8946217a0b

Applied patches 2 and 3.

Bart

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andy Shevchenko

author reviewer

2023-12-18 13:36 UTC #25 lore raw

Quoted 1 line · Andy Shevchenko

On Mon, Dec 18, 2023 at 01:43:40PM +0100, Bartosz Golaszewski wrote:

...

Quoted 1 line

Thank you! I guess you forgot to add --sign-off to the git merge ...

Sorry, it's --signoff.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Bartosz Golaszewski

2023-12-18 13:38 UTC #26 lore raw

Quoted 10 lines · Andy Shevchenko

Quoted 1 line · Andy Shevchenko
On Mon, Dec 18, 2023 at 01:43:40PM +0100, Bartosz Golaszewski wrote:
...
Quoted 1 line
Thank you! I guess you forgot to add --sign-off to the git merge ...
Sorry, it's --signoff.

I never sign-off on merges though, is it mandatory? Probably not as there are no warnings from next like for regular commits about missing sign-offs.

Bart

Quoted 5 lines

--
With Best Regards,
Andy Shevchenko

Andy Shevchenko

author reviewer

2023-12-18 15:02 UTC #27 lore raw

Quoted 4 lines · Bartosz Golaszewski

Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Andy Shevchenko
On Mon, Dec 18, 2023 at 01:43:40PM +0100, Bartosz Golaszewski wrote:

...

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
Thank you! I guess you forgot to add --sign-off to the git merge ...
Sorry, it's --signoff.
I never sign-off on merges though, is it mandatory? Probably not as there are no warnings from next like for regular commits about missing sign-offs.

No idea. I do it as it is harmless, and makes commit more robust.

For me it's fine, but I leave for me to exclaim later "Yay, had told ya!" :-)

Signature · 2 lines

With Best Regards,
Andy Shevchenko