[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230530125727.688b6042@md1za8fc.ad001.siemens.net>
Date: Tue, 30 May 2023 12:57:27 +0200
From: Henning Schild <henning.schild@...mens.com>
To: simon.guinot@...uanux.org
Cc: Linus Walleij <linus.walleij@...aro.org>, xingtong_wu@....com,
brgl@...ev.pl, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, xingtong.wu@...mens.com
Subject: Re: [PATCH v2 1/1] gpio-f7188x: fix base values conflicts with
other gpio pins
Am Mon, 29 May 2023 15:54:36 +0200
schrieb simon.guinot@...uanux.org:
> On Mon, May 29, 2023 at 03:03:28PM +0200, Linus Walleij wrote:
> > On Mon, May 29, 2023 at 2:27 PM <simon.guinot@...uanux.org> wrote:
> >
> > > It would be nice if a pin number found in the device datasheet
> > > could still be converted into a Linux GPIO number by adding the
> > > base of the first bank.
> >
> > We actively discourage this kind of mapping because of reasons
> > stated in drivers/gpio/TODO: we want dynamic number allocation to
> > be the norm.
>
> Hi Linus,
>
> Sure but it would be nice to have a dynamic base applied to a
> controller (and not to each chip of this controller), and to respect
> the interval between the chips (as stated in the controllers
> datasheets).
You mentioned yourself that there are the holes to take care of. And
the symbols/names from the SPECs seem to be octal numbers to me. While
humans might prefer decimal and the code seems to be hexadecimal.
Not sure the numbers have ever been too useful for humans. And once we
change one base (bank0) we actually already break user-land that so far
failed to discover the base from sysfs (bug in that user-land code, not
our problem).
I am with Linus on that one, we should try.
Henning
> This way the assignation would be dynamic and the pin numbers found in
> controller datasheet would be meaningful as well.
>
> Simon
Powered by blists - more mailing lists