linux-kernel - Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs

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] [day] [month] [year] [list]

Message-ID: <20130827075247.GB6152@lee--X1>
Date:	Tue, 27 Aug 2013 08:52:47 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting
 with ATAGs

On Fri, 23 Aug 2013, Linus Walleij wrote:

> On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> 
> > It is not true at all that all HREFs have the STUIB mounted.
> 
> Hm I'm confused here...
> 
> arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff
> so forget about the misplaced comments.
> 
> For *all* HREF boards. As it is included from both
> [ste-]hrefprev60.dts and [ste-]hrefv60plus.dts
> 
> However it is only really mounted on some of the HREFs,
> and the following stays valid:
> 
> > This detection needs to stay for now, unless we go and define
> > in the device tree which UIB is mounted, which would be unfortunate
> > as we can very well auto-detect it, and that makes it easier for
> > a user to just swap the UIB and test the other toch screen
> > (for example).
> 
> So it would be really nice to keep this autodetection.
> 
> What would be nice if we could mark all the STUIB as
> "disabled" in the device trees, and then augment the device tree
> at boot depending on if we find something at 0x44 as in this
> test:
> 
> > -       /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
> > -       ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
> > -                       I2C_SMBUS_QUICK, NULL);
> 
> And then mark these as "okay" in the DT.
> 
> That's pretty high-tech but I bet we can pull it off (and set
> a good example).

Well, this stuff is possible, but it doesn't really have anything to
do with this patch-set. We can reuse 'some' of this code, but we'd need
to think of a new way to represent it. That coupled with the fact that
the Device Tree boot doesn't use any of this stuff yet leads to
believe we can keep this removal patch in the set and re-introduce the
key parts when we've had a chat about the new implementation.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/