Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHp75Veo30c0BWb4Fykgvd-czSnEXsyA8wyMTeKQdS49=e5-nw@mail.gmail.com>
 <20220417165208.39754-1-schspa@gmail.com> <CAHp75Vc8HwheQVOpcn_Lxk-bOOMLybr=m6OdO7mJ-vE9xywBLg@mail.gmail.com>
 <CAMA88Tr6NvfEiPYnt0A60GiQKiiT6LT7X83GRku-4PDcG2EtoA@mail.gmail.com>
 <CAHp75VfcxACmuw5pwPgSB9ud06hWtHCUrMifU1rZJ+h+dwG+bg@mail.gmail.com> <CAHp75Vchpi0Cvkz5krA0LEZBj-fQTXxbEBzpKxU96mcDRGY--A@mail.gmail.com>
In-Reply-To: <CAHp75Vchpi0Cvkz5krA0LEZBj-fQTXxbEBzpKxU96mcDRGY--A@mail.gmail.com>
From:   Schspa Shi <schspa@gmail.com>
Date:   Mon, 18 Apr 2022 23:43:14 +0800
Message-ID: <CAMA88TruFbCZbvq84ep5NbSdxDgi-mPX2iXWk4c2qA-etMA8QQ@mail.gmail.com>
Subject: Re: [PATCH] gpio: use raw spinlock for gpio chip shadowed data
To:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "brgl@bgdev.pl" <brgl@bgdev.pl>
Cc:     "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "fancer.lancer@gmail.com" <fancer.lancer@gmail.com>,
        "hoan@os.amperecomputing.com" <hoan@os.amperecomputing.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "opendmb@gmail.com" <opendmb@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Mon, Apr 18, 2022 at 2:38 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Mon, Apr 18, 2022 at 6:07 AM Schspa Shi <schspa@gmail.com> wrote:
>> > Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>>
>> ...
>>
>> > >   drivers/gpio/gpio-mmio.c    | 22 +++++++++++-----------
>> > >   include/linux/gpio/driver.h |  2 +-
>> > >
>> > > You can=E2=80=99t do it for one driver only. As I told it will requi=
re too much of additional churn to make this to be series.
>> > >
>> >
>> > It seems I have misunderstood your "too much of additional churn". Can
>> > you explain it?
>> > The gpio-mmio.c and driver.h here are the basics of other gpio
>> > drivers. In my opinion, these two files
>> > belong to the basic code of gpio, and functions such as bgpio_init are
>> > declared in
>> > include/linux/gpio/driver.h and implemented in
>> > drivers/gpio/gpio-mmio.c. So there is no churn.
>>
>> When you change the member of the data structure, you have to change
>> all its users. You can't change only one at a time because it will be
>> a (compile-time) bisectability issue.


Yes, I understand and will take for bisectability use case for the next tim=
e.

>
> Answering your question here, it will require moving to union with an
> additional member and corresponding core changes, convert all drivers
> one-by-one, and remove the old type. It's not worth doing it, but as I
> said let maintainers decide.

Okay, sorry for my misunderstanding, I thought you were saying it's
bad to modify too many different files in one patch, so I split the
patch into a series of patchsets.

So, let Linus Walleij or Bartosz Golaszewski to decide for it ?
I have the same options as you, it's a small change, and no need to
trouble everyone for it.

Because this structure will be used as the same instance in multiple
files, even if we change this variable to union first, it can be
compiled, but the program will still not work properly. This is
because bgpio_init is initialized with the type of raw_spinlock_t,
but is still accessed as spinlock_t in other drivers, which is a
serious abnormal initialization.