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;
Date:   Fri, 18 Oct 2019 06:15:15 +0900
From:   Daniel Palmer <daniel@0x0f.com>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/4] ARM: mstar: Add machine for MStar infinity family
 SoCs
Message-ID: <20191017211513.GA12691@shiro>
References: <20191014061617.10296-1-daniel@0x0f.com>
 <20191014061617.10296-2-daniel@0x0f.com>
 <CAK8P3a2U7U31eF_POU2=eCU+E1DH-wnR2uHr-VZYWLy25hLjKg@mail.gmail.com>
 <20191016203219.GA5191@shiro>
 <CAK8P3a2Tqpwg6=3N2DhcDj9JMo6jt0sY+sYmnNmzZ5Rcao=iMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a2Tqpwg6=3N2DhcDj9JMo6jt0sY+sYmnNmzZ5Rcao=iMA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 17, 2019 at 03:02:22PM +0200, Arnd Bergmann wrote:
> > I've moved this into infinity_barriers_init() using ioremap() as suggested.
> > I'd like to keep the fixed remap address for now as there are some
> > drivers in the vendor code that might be useful until rewrites are done but
> > are littered with hard coded addresses.
>
> Maybe keep the infinity_io_desc as an out-of-tree patch then? You can
> simply do both, and ioremap() will return the hardcoded address.

That makes sense.
 
> > I've taken the lock out and tested that the ethernet isn't sending garbage
> > and everything looks good.
> 
> I would not expect a missing spinlock to have an observable effect, the
> question is more whether it's correct in all rare corner cases where
> the barrier is interrupted and the interrupt handler uses another barrier.
> 
> I think it is, but I would recommend adding a comment to explain this if
> you drop the spinlock. (or a comment about why this works with fiq if you
> keep the lock).

I think I'll drop the lock for now and add it back if it becomes apparent
it's needed. I suspect it was added in the vendor code out of habit instead
of need.

Thanks for the input.

Daniel