MIME-Version: 1.0
References: <1553281120-22139-1-git-send-email-pozega.tomislav@gmail.com>
 <3337086.qEUs9xMCTV@debian64> <fe853ec8-0dca-d931-8632-fbe4df5cfaf8@broadcom.com>
 <edc38f32-977a-53f5-babd-605775326a20@broadcom.com> <CABvG-CUXHgJ1ZUfsZw6ajzR=4DjnRRNrPmF147mZsoWJBjp-jQ@mail.gmail.com>
 <c13da25c-9116-9388-8e40-96bac8dca087@candelatech.com>
In-Reply-To: <c13da25c-9116-9388-8e40-96bac8dca087@candelatech.com>
From:   =?UTF-8?Q?Micha=C5=82_Kazior?= <kazikcz@gmail.com>
Date:   Mon, 25 Mar 2019 21:08:30 +0100
Message-ID: <CABvG-CWP4y4MU1pJB8ZSpLPPYMkQ+=kQt1zRoUJW=0dMLbD5WQ@mail.gmail.com>
Subject: Re: [PATCH] ath10k: reset chip after supported check
To:     Ben Greear <greearb@candelatech.com>
Cc:     Arend Van Spriel <arend.vanspriel@broadcom.com>,
        Christian Lamparter <chunkeey@gmail.com>,
        =?UTF-8?Q?Tomislav_Po=C5=BEega?= <pozega.tomislav@gmail.com>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        openwrt-devel@lists.openwrt.org, Kalle Valo <kvalo@codeaurora.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, 25 Mar 2019 at 16:55, Ben Greear <greearb@candelatech.com> wrote:
> On 3/25/19 5:14 AM, Micha=C5=82 Kazior wrote:
> > On Sat, 23 Mar 2019 at 08:20, Arend Van Spriel
> > <arend.vanspriel@broadcom.com> wrote:
> >>
> >> * resending with corrected email address from Kalle
> >> --------------------------------------------------------------------
> >> + Micha=C5=82
> >
> > Thanks!
> >
> >
> >> On 3/22/2019 8:25 PM, Christian Lamparter wrote:
> >>   > On Friday, March 22, 2019 7:58:40 PM CET Tomislav Po=C5=BEega wrot=
e:
> >>   >> When chip reset is done before the chip is checked if supported
> >>   >> there will be crash. Previous behaviour caused bootloops on
> >>   >> Archer C7 v1 units, this patch allows clean device boot without
> >>   >> excluding ath10k driver.
> >
> > Can you elaborate more a bit? What kind of crashes are you seeing?
> > What does the bootloop look like? Do you have uart connected to
> > diagnose?
> >
> > Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported
> > by ath10k? I recall the v1 chip was really buggy and required
> > hammering registers sometimes to get things working.
>
> The crash is related to the v1 chip.  Is there a good way to detect
> that this is the chip in question and only apply this work-around
> for the problem chip?

I don't know of any good way to do that.

You could consider device-tree but that would be no different from
having a module blacklist in the C7v1 build recipe, or to not build
the module at all. That is unless you actually want to make v1 chip
work with ath10k at which point there's more fun to be had before it
can actually work.


Micha=C5=82