Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [BUG] SPI broken for SPI based panel drivers
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <20201201162035.GK5239@sirena.org.uk>
Date:   Tue, 1 Dec 2020 17:41:54 +0100
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Sven Van Asbroeck <thesven73@gmail.com>,
        kernel list <linux-kernel@vger.kernel.org>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@openphoenux.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D0E8CDA-96EA-4900-B5B2-0AD371EAD046@goldelico.com>
References: <2D7916FA-678F-4236-B478-C953CADF2FFA@goldelico.com> <CAGngYiXgc_m2A7Wihxuhzm-u4qH-JZgxHjke653zvyT45jMU7Q@mail.gmail.com> <4AC29229-9542-4E77-B993-217E29C7E209@goldelico.com> <20201201121620.GB5239@sirena.org.uk> <A499CCB9-F2EC-4F24-AA79-5A7FA6A092A9@goldelico.com> <CACRpkdYf2dUF6PjYcvnsKDPoxXPWiWKKAqpik4-2AAQjRmatfw@mail.gmail.com> <20201201162035.GK5239@sirena.org.uk>
To:     Mark Brown <broonie@kernel.org>
Precedence: bulk


> Am 01.12.2020 um 17:20 schrieb Mark Brown <broonie@kernel.org>:
>=20
> On Tue, Dec 01, 2020 at 03:20:12PM +0100, Linus Walleij wrote:
>=20
>> The reason why I shoot in the dark to convert all SPI
>> drivers to use GPIO descriptors instead of the global
>> GPIO numberspace is detailed in drivers/gpio/TODO
>> so I will not repeat it here.
>=20
>> I don't know if much can be done about it other than
>> having better programmers than me at the task. Or
>> less tired when they write the patch. etc.
>=20
> I think the problem here is more to do with where we started than =
where
> we're going or how we got there - things have been glued together or
> happened to work in ways that mean I'm not sure we reasonably =
understand
> the situation we started from or all the requirements it has.  As you
> say I'm not sure anything beyond throwing the API away and starting
> afresh would really help here, but that's not really how we tend to do
> things for a bunch of very good reasons.

I think the key problem is GPIO_ACTIVE_HIGH 0 and GPIO_ACTIVE_LOW 1
in device tree blobs. But that is so fundamental that we have to live =
with it.
So I guess that even a new API from scratch wouldn't improve that.=