linux-kernel - Re: [PATCH] mfd/ab8500: support AB9540 variant

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: <CACRpkdZjh6J_=DG58DkWO0bnj2Np3ujagcdOgNtYq2GfN30uRQ@mail.gmail.com>
Date:	Wed, 1 Feb 2012 15:42:59 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	Michel Jaouen <michel.jaouen@...ricsson.com>,
	Maxime Coquelin <maxime.coquelin@...ericsson.com>,
	Alex Macro <alex.macro@...ricsson.com>
Subject: Re: [PATCH] mfd/ab8500: support AB9540 variant

On Wed, Feb 1, 2012 at 12:31 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, Feb 01, 2012 at 12:02:35PM +0100, Linus Walleij wrote:
>
>> identifier field. If possible, we fall back on auto-detecting
>> the AB variant. The necessary deviations are factored into
>> the driver and board data.
>
> This seems a bit weird - I would expect the silicon to be more accurate
> than user provided platform data.

Well, that would have been good. As it happens, the hardware
is reusing the same ID for four widely different ASICs.

Second, if you try to even read it on older chip variants, it fails
with I2C errors. So for older chips we have to pass this through
platform data.

> I'd expect the driver to always check
> the information provided by the device and at least log if there's a
> difference.

Well, I will just get an I2C error back in the case where it is
passed from platform data, so it will sadly only delay the boot.

For newer ASICs we solve it by not providing platform data
and instead fall back to reading chip revision.

I will write this into the code as a comment so it's clear.

> It'd also be easier to review the patch if there was some description of
> the differences (or there were a series of patches adding
> parameterisation for relevant things followed by one adding the new
> device).

OK breaking it apart...

Yours,
Linus Walleij
--
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/