On Mon, Jul 31, 2023 at 10:46 AM Hugo Villeneuve <hugo@xxxxxxxxxxx> wrote:
>
> On Mon, 31 Jul 2023 09:31:53 -0600
> Rob Herring <robh+dt@xxxxxxxxxx> wrote:
>
> > On Mon, Jul 24, 2023 at 9:54 AM Hugo Villeneuve <hugo@xxxxxxxxxxx> wrote:
> > >
> > > On Sat, 22 Jul 2023 17:15:26 +0200
> > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > > > >
> > > > > > On Fri, Jul 21, 2023 at 10:19 AM Hugo Villeneuve <hugo@xxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > From: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx>
> > > > > > >
> > > > > > > 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/758
> >
> > Do 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.
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
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?
Rob
