Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190402103203.14959-1-gregkh@linuxfoundation.org>
 <20190402103203.14959-4-gregkh@linuxfoundation.org> <CACmrr9hZRiw10dDVcvFUFB7ZFzFq-WfELRXnTLOM_j5LoNnw3A@mail.gmail.com>
 <87r2ak18yy.fsf@notabene.neil.brown.name> <20190402204658.GA5187@habor.localdomain>
In-Reply-To: <20190402204658.GA5187@habor.localdomain>
From:   George Hilliard <thirtythreeforty@gmail.com>
Date:   Wed, 3 Apr 2019 14:35:37 -0500
Message-ID: <CACmrr9gRRTpamy-0oQafzZ1a7jZZcHOQhGU8ghYLLD3XsEU3XA@mail.gmail.com>
Subject: Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
To:     NeilBrown <neil@brown.name>,
        George Hilliard <thirtythreeforty@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org, Nishad Kamdar <nishadkamdar@gmail.com>,
        linux-kernel@vger.kernel.org,
        Sergej Perschin <ser.perschin@gmail.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        John Crispin <blogic@openwrt.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 2, 2019 at 3:45 PM Christian L=C3=BCtke-Stetzkamp
<christian@lkamp.de> wrote:
> There are two other larger differences that I found during my
> work. One is that drivers/mmc/host/mtk-sd.c has much more features,
> like voltage and clock handling and some support for high speed
> modes. I don't know if these features are required/useful for this
> device.

For what it's worth, I found an old forum post of someone who was
dealing with a crashy kernel on their mt7688.  They removed the
mt7621-mmc driver and hacked the clock code out of the mainline
driver.  Apparently it worked.  I never got around to duplicating
their work, however.  (I too ran into severe instability problems with
the mt7621-mmc driver, but they only appeared in conjunction with
using the SLOB allocator.  I could never debug it because when JTAG
was turned on, the SDMC peripheral was disabled for some reason I
never discovered.  More info on that if someone is interested.)

The correct way to do this would be to have a "compatible" flag that
bypassed the clock handling code.  I don't think there are any
relevant clocks to set up on the MT7628/MT7688 - the MSDC peripheral
does not appear in the clock plan.

> The other thing is the card detect handling. This driver is
> doing the card detect / read only detection on its own, where the in
> tree one just uses some default gpio functions there and I don't know
> weather this must be changed or weather there is a gpio driver for the
> mt7621.

There is a "mtk,mt7621-gpio"-compatible GPIO driver available.
Probably it would work with GPIO on new hardware that did not to route
CD to the CD pin, because the CD pin is muxed using the same "SD card"
pin state as the SD data pins.  I do not know if it is possible for
the GPIO peripheral to read the pin while it is muxed to the SD
controller, as would be necessary for existing hardware.

George