stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>,
	stable <stable@vger.kernel.org>,
	regressions@lists.linux.dev,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Thierry Reding <treding@nvidia.com>,
	Vidya Sagar <vidyas@nvidia.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Edmond Chung <edmondchung@google.com>,
	Andrew Chant <achant@google.com>,
	Will McVicker <willmcvicker@google.com>,
	Sergio Tanzilli <tanzilli@acmesystems.it>
Subject: Re: [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)
Date: Fri, 20 May 2022 14:28:19 -0300	[thread overview]
Message-ID: <CACjc_5oRRHdCjbSEeMMY2DeJRyFDcbQ2Vk7vaFC9h+kas8zC9g@mail.gmail.com> (raw)
In-Reply-To: <a0ce4372-df94-a19c-063d-274e65da7c38@leemhuis.info>

Hi Thorsten,

On Fri, May 20, 2022 at 6:12 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 16.02.22 15:40, Bartosz Golaszewski wrote:
> > On Tue, Feb 15, 2022 at 10:56 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >> On Mon, Feb 14, 2022 at 12:24 AM Marcelo Roberto Jimenez
> >> <marcelo.jimenez@gmail.com> wrote:
> >>> On Sat, Feb 12, 2022 at 1:55 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >>>> I am curious about the usecases and how deeply you have built
> >>>> yourselves into this.
> >>>
> >>> I don't know if I understand what you mean, sorry.
> >>
> >> Why does the user need the sysfs ABI? What is it used for?
> >>
> >> I.e what is the actual use case?
> >>
> >>>>> In any case, the upstream file should be enough to test the issue reported here.
> >>>>
> >>>> The thing is that upstream isn't super happy that you have been
> >>>> making yourselves dependent on features that we are actively
> >>>> discouraging and then demanding that we support these features.
> >>>
> >>> Hum, demanding seems to be a strong word for what I am doing here.
> >>>
> >>> Deprecated should not mean broken. My point is: the API seems to be
> >>> currently broken. User space apps got broken, that's a fact. I even
> >>> took the time to bisect the kernel and show you which commit broke it.
> >>> So, no, I am not demanding. More like reporting and providing a
> >>> temporary solution to those with a similar problem.
> >>>
> >>> Maybe it is time to remove the API, but this is up to "upstream".
> >>> Leaving the API broken seems pointless and unproductive.
> >>>
> >>> Sorry for the "not super happiness of upstream", but maybe upstream
> >>> got me wrong.
> >>>
> >>> We are not "making ourselves dependent on features ...". The API was
> >>> there. We used it. Now it is deprecated, ok, we should move on. I got
> >>> the message.
> >>
> >> Ouch I deserved some slamming for this.
> >>
> >> I'm sorry if I came across as harsh :(
> >>
> >> I just don't know how to properly push for this.
> >>
> >> I have even pushed the option of the deprecated sysfs ABI
> >> behind the CONFIG_EXPERT option, which should mean that
> >> the kernel config has been made by someone who has checked
> >> the option "yes I am an expert I know what I am doing"
> >> yet failed to observe that this ABI is obsoleted since 5 years
> >> and hence failed to be an expert.
> >>
> >> Of course the ABI (not API really) needs to be fixed if we can find the
> >> problem. It's frustrating that fixing it seems to fix broken other
> >> features which are not deprecated, hence the annoyance on my
> >> part.
> >>
> >
> > I'm afraid we'll earn ourselves a good old LinusRant if we keep
> > pushing the character device as a solution to the problem here.
> > Marcelo is right after all: he used an existing user interface, the
> > interface broke, it must be fixed.
> >
> > I would prefer to find a solution that fixes Marcelo's issue while
> > keeping the offending patches in tree but it seems like the issue is
> > more complicated and will require some rework of the sysfs interface.
> >
> > In which case unless there are objections I lean towards reverting the
> > relevant commits.
>
> Reviving and old thread, hence a quick reminder: The patch at the start
> of this thread was applied and then reverted in 56e337f2cf13 with this text:
>
> ```
> This commit - while attempting to fix a regression - has caused a number
> of other problems. As the fallout from it is more significant than the
> initial problem itself, revert it for now before we find a correct
> solution.
> ```
>
> I still have this on my list of open regressions and that made me
> wonder: is anyone working on a "correct solution" (or was one even
> applied and I missed it)? Or is the situation so tricky that we better
> leave everything as it is? Marcelo, do you still care?

The purpose of my patch was to revert the patch that was causing the
hardware I work with to fail. But reverting that patch had bad
consequences in other hardware, so I really do not think that my patch
should go in.

Following Linus Walleij's advice, we are stopping using sysfs for
gpio, so in the near future that patch will be irrelevant for me. On
the other hand, a few people using recent kernels have tried my patch
successfully, so it can be used as a temporary transition hack.

Also, the patch exposes a serious problem with the sysfs gpio, which
is currently broken. Maybe we should consider removing the interface
in a near future release, as it has been advocated several times
before, since it has long been deprecated, has a much better
substitute API and, the worse part, it is broken and no one seems to
have a high priority in fixing it.

IIRC, the last time I read, the kernel documentation said that the API
would be removed in 2020, so we are a bit late :). I know that
removing an API has lots of implications, so the consequences must be
carefully balanced.

> Ciao, Thorsten

Best regards,
Marcelo.

  reply	other threads:[~2022-05-20 17:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 15:35 Marcelo Roberto Jimenez
2021-12-18  6:28 ` Thorsten Leemhuis
2021-12-20 14:57   ` Bartosz Golaszewski
2021-12-20 15:14     ` Geert Uytterhoeven
2021-12-20 19:24       ` Will McVicker
2021-12-20 20:41         ` Marcelo Roberto Jimenez
2021-12-20 20:41       ` Marcelo Roberto Jimenez
2021-12-20 20:41     ` Marcelo Roberto Jimenez
2022-01-10  7:02       ` Thorsten Leemhuis
2022-01-12  0:09         ` Marcelo Roberto Jimenez
2022-02-08 12:24           ` Thorsten Leemhuis
2022-02-17 19:11           ` Thierry Reding
2022-02-11  0:02 ` Linus Walleij
2022-02-11 22:36   ` Marcelo Roberto Jimenez
2022-02-12 16:54     ` Linus Walleij
2022-02-13 23:23       ` Marcelo Roberto Jimenez
2022-02-15 21:56         ` Linus Walleij
2022-02-16 14:40           ` Bartosz Golaszewski
2022-03-04  7:13             ` Thorsten Leemhuis
2022-03-07  9:58               ` Bartosz Golaszewski
2022-03-07 10:12                 ` Thorsten Leemhuis
2022-05-20  9:12             ` Thorsten Leemhuis
2022-05-20 17:28               ` Marcelo Roberto Jimenez [this message]
2022-03-14 15:55 ` Michael Walle
2022-03-15 15:32   ` Bartosz Golaszewski
2022-03-15 15:45     ` Michael Walle
2022-03-17  8:37       ` Andy Shevchenko
2022-03-17  8:48         ` Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACjc_5oRRHdCjbSEeMMY2DeJRyFDcbQ2Vk7vaFC9h+kas8zC9g@mail.gmail.com \
    --to=marcelo.jimenez@gmail.com \
    --cc=achant@google.com \
    --cc=brgl@bgdev.pl \
    --cc=edmondchung@google.com \
    --cc=geert@linux-m68k.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=sfr@canb.auug.org.au \
    --cc=stable@vger.kernel.org \
    --cc=tanzilli@acmesystems.it \
    --cc=treding@nvidia.com \
    --cc=vidyas@nvidia.com \
    --cc=willmcvicker@google.com \
    --subject='Re: [PATCH] gpio: Revert regression in sysfs-gpio (gpiolib.c)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).