linux-kernel - Re: [PATCH 4/9] ASoC: imx: Don't use {en,dis}able

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKGA1bmMqyL4gyLYcanEH=R=HuBjRCNRLjUEWCj8wmpi3HuL0g@mail.gmail.com>
Date:	Mon, 6 Aug 2012 15:39:50 -0500
From:	Matt Sealey <matt@...esi-usa.com>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	John Stultz <john.stultz@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org,
	Sascha Hauer <kernel@...gutronix.de>
Subject: Re: [PATCH 4/9] ASoC: imx: Don't use {en,dis}able_fiq() calls

On Mon, Aug 6, 2012 at 3:16 PM, Robert Schwebel
<r.schwebel@...gutronix.de> wrote:
> On Mon, Aug 06, 2012 at 08:37:34PM +0100, Mark Brown wrote:
>> As far as I can tell nobody's really running much up to date mainline
>> on older i.MX processors, all the work is going on the new stuff and
>> most of the board are on either vendor BSPs or older kernels.
>
> That's not true; we still run MX25, MX27, MX35, MX28 on mainline in
> active projects.

I think Shawn Guo (FSL/Linaro) would also disagree, since he's just
posted a large amount of MXS patches to fix up the board for device
trees, and Arnd is pulling them.

Work is ongoing, it would be awful to delete something people really
relied on or were in progress fixing (ahem). If they get up to audio
in the near future the audio FIQ stuff would just end up being
resubmitted almost verbatim... that seems like unnecessary churn.

As far as I know, the FIQ usage is quite valid for the processor it
needs to run on (MX21/27/28, right?) in the modes it runs in (AC97 on
these processors, and maybe MX35 too), and I'm just trying to figure
out what the steps are for

* making sure it doesn't get built for architectures/variants it's
certainly NOT required on (imx_v6_v7_defconfig, if it actually enabled
audio, that is - in fact, audio should be enabled as more one of the
boards supported defines it in the device tree) which would amount to
two seperate patches, one for the defconfig, one for the CONFIG item.

I did note that SND_SOC_EUKREA_TLV320 enables FIQ but it also depends
on MX51 which makes me think this need to be split, too, so that MX51
boards don't have it but MX2/MX3 do.

* if it is built then it's built as ARM code (redundant, as previously
stated, but would have stopped me from swearing at my build box when I
hit the issue yet again) which could be a patch or could be ignored.
I'd rather discuss this here than clutter the ML with several respins
of a patch, let's get an opinion first - to .arm or no to .arm?

* make sure there's no weird FIQ stuff floating around that has so far
relied on SND_SOC_IMX_PCM_FIQ doing select FIQ before I make it not
compile in for other boards (since otherwise no i.MX processor selects
FIQ if they're not using that driver, it could be simply coincidence
nobody noticed). I don't want to be the one submitting a patch I can't
test which mysteriously breaks every MX28 on the planet (since Rob,
Shawn, Sascha might be the ones swearing at me instead)

* making sure someone's actually testing audio as above... and
where/if/when the MX28 audio stuff is going in the future und so
weiter..

I guess I need Sascha to pipe up and tell me what the code is needed
for exactly again.. and someone to test the result of the changes..

-- 
Matt Sealey <matt@...esi-usa.com>
Product Development Analyst, Genesi USA, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/