Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220414214337.311880-1-linus.walleij@linaro.org> <f4deb182-ec18-6744-2c4c-adaed4ef7a33@collabora.com>
In-Reply-To: <f4deb182-ec18-6744-2c4c-adaed4ef7a33@collabora.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Fri, 22 Apr 2022 23:50:51 +0200
Message-ID: <CACRpkdbZnWJgkS2a0xXs_WG40jz6+aTSPt743Zigd0KZ8R=yww@mail.gmail.com>
Subject: Re: [PATCH] dt-bindings: gnss: Add Broacom BCM4751 family bindings
To:     Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc:     Johan Hovold <johan@kernel.org>, Rob Herring <robh+dt@kernel.org>,
        David Heidelberg <david.heidelberg@collabora.com>,
        Svyatoslav Ryhel <clamor95@gmail.com>,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Apr 18, 2022 at 1:19 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:

> What are the chances of seeing the kernel driver for BCM4751+?

The kernel does not normally drive the GPS. The kernel has a small driver
dealing with hardware power on/off of the GPS and exposing
/dev/gnss0 to userspace.

See Johans lecture at:
https://events19.linuxfoundation.org/wp-content/uploads/2017/12/The-GNSS-Subsystem-Johan-Hovold-Hovold-Consulting-AB.pdf

>  There are
> myriads of Android devices using that GPS chip. Previously the
> proprietary firmware interface of BCM4751 was an obstacle for addition
> of the driver to upstream kernel, did anything change?

Actually there is nothing stopping us from anyway merging device tree
bindings, even if no driver is on the horizon for Linux. The DT bindings
are not a Linux kernel thing. Actually we merged bindings like that in
the past. It makes it possible to create complete device trees, which
is nice. A driver for Linux can be slotted in at a later point.

Anyway, that is the boring answer.

Many if not all GPS:es (as all Wireless chips) have proprietary firmware
interfaces. This is normal. GPS:es are special since by tradition the
stack using them is in userspace. There exist free software userspace
stacks for misc GPS:es.

gpsd is the most common userspace daemon for GPS.
gpsd will then talk to /dev/gnss0 as any other TTY IIUC.

Replicant has a free implementation of the "MEIF" API for this GPS,
I think what is needed is really for someone to pick up, polish and
contribute that to gpsd
https://git.replicant.us/contrib/PaulK/bcm4751/

Yours,
Linus Walleij