Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards

From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org,
	wens-jdAy2FN1RRM@public.gmane.org,
	sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	Charles Keepax
	<ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Subject: Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
Date: Thu, 24 Apr 2014 14:30:36 +0100	[thread overview]
Message-ID: <20140424133036.GY12304@sirena.org.uk> (raw)
In-Reply-To: <20140423202546.GA3890-OP/Sd6KM9CusbfqNwF1Yyl6hYfS7NtTn@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Wed, Apr 23, 2014 at 10:25:46PM +0200, Carlo Caione wrote:

> I'm having a really hard time with this problem, so any hint is welcome
> :) The small modification I'm using on top of the patches in this series
> is here: http://bpaste.net/show/228330/

> Unfortunately as I said I got this when booting:
> http://bpaste.net/show/nUhUTzELT32v9HNPathL/

Huh, actually the arizona drivers do show this (it was being masked in
my logs by another unrelated bug).  I guess the Wolfson guys aren't
working with upstream much (though Charles did write the orignal code
here...).

The issue is the MFD core, it shouldn't be using managed allocations
here - the error reported by the assert is entirely correct.  If the
CODEC driver is bound and unbound it'll not be possible to reload it
as things stand.  

Your driver is correct but the implementation needs to be fixed -
possibly with an API change on free since at the minute the cells to be
freed don't get passed back into the MFD core when deallocating.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]