On Mon, 31 Jul 2023 12:04:45 -0600 Rob Herring robh+dt@kernel.org wrote:
On Mon, Jul 31, 2023 at 10:46 AM Hugo Villeneuve hugo@hugovil.com wrote:
On Mon, 31 Jul 2023 09:31:53 -0600 Rob Herring robh+dt@kernel.org wrote:
On Mon, Jul 24, 2023 at 9:54 AM Hugo Villeneuve hugo@hugovil.com wrote:
On Sat, 22 Jul 2023 17:15:26 +0200 Greg KH gregkh@linuxfoundation.org wrote:
On Sat, Jul 22, 2023 at 10:47:24AM -0400, Hugo Villeneuve wrote:
On Fri, 21 Jul 2023 13:24:19 -0600 Rob Herring robh+dt@kernel.org wrote:
> On Fri, Jul 21, 2023 at 10:19 AM Hugo Villeneuve hugo@hugovil.com wrote: > > > > From: Hugo Villeneuve hvilleneuve@dimonoff.com > > > > Commit 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines") > > and commit 21144bab4f11 ("sc16is7xx: Handle modem status lines") > > changed the function of the GPIOs pins to act as modem control > > lines without any possibility of selecting GPIO function. > > Requiring a new DT property is not fixing a kernel regression. You > should be returning the kernel to original behavior and then have a > new DT property for new behavior.
Hi Rob, please read the entire patch history starting from V1 and you will understand why this course of action was not selected.
That's not going to happen, sorry, you need to explain it here, in this patch series, why a specific action is being taken over another one, as no one has time to go dig through past history, sorry.
Hi Rob, I initially submitted a patch to revert the kernel to original behavior, but it created more problems because the patch was unfortunately split in two separate patches, and mixed with other non closely-related changes. It was also noted to me that reverting to the old behavior would break things for some users.
It was suggested to me by a more experienced kernel developer to "suggest a fix, instead of hurrying a revert":
https://lkml.org/lkml/2023/5/17/758Do I have to go read this to decipher the justification and reasoning? When Greg says "in this patch series", he means in the commit messages of the patches. You send v9 already and it doesn't have that. The patchset needs to stand on its own summarizing any relevant prior discussions.
I never suggested doing a revert.
Hi Rob, I am sorry, but this is exactly what I "deciphered" from your original email.
I am trying very hard to understand exactly what you mean, but it is not that obvious for me. If something is not clear in my commit message, I will try to improve it. But before, let's try to focus on making sure I understand more clearly what you want exactly.
Obviously, someone still wants the new feature.
I assume that you refer to the "new feature" as what was added in the commit 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines")?
Shrug. It's one of the 2 commits mentioned, I don't know which one exactly. Whichever one changed default behavior from use GPIOs to use modem ctrl lines.
Reading it again, I *think* this patch is correct. Default behavior is restored to use GPIOs. The DT property is needed to enable modem ctrl lines.
Hi, this is correct.
What's not okay is just saying, these platforms may or may not need an update:
arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts mips/boot/dts/ingenic/cu1830-neo.dts mips/boot/dts/ingenic/cu1000-neo.dts
Yes, my bad. I initially mentioned them and hoped to get some feedback, which I never got, and I kind of forgot about it.
You need to figure that out. Have you checked with maintainers of these boards? When were they added and by who? At the same time or by the same person would be a good indication the platform uses modem ctrl lines. Or were these platforms in use before adding modem ctrl support? Then they probably use GPIOs or nothing.
If there are platforms which would regress if the modem ctrl feature was just reverted, which ones are those?
Ok, let me do some checks and get back to you on this.
Thank you, Hugo.