linux-kernel - Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS

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: <20140724145621.GX23220@titan.lakedaemon.net>
Date:	Thu, 24 Jul 2014 10:56:21 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Benoit Masson <benoitm@...enite.com>,
	Arnd Bergmann <arnd@...db.de>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Benoit Masson <yahoo@...enite.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...glemail.com>
Subject: Re: [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega
 ix4-300d NAS

On Thu, Jul 24, 2014 at 04:29:18PM +0200, Andrew Lunn wrote:
> > The only outstanding point (Arnd?), is that I think it's ok to have the
> > i2c...a0 compatible string in the dts files, but Andrew seems to think
> > otherwise.  Is that still true Andrew?
> 
> Hi Jason
> 
> I can live with i2c...a0 compatible string, but it has minor problems:
> 
> 1) The binding Documentation says not to do it. So we are ignoring our
>    own documentation.

This can be updated.

> 2) It seems likely that at some point the OEM will swap to B1 revision
>    SoCs. The i2c device then does not require this quirk, but we have
>    hard coded in the DT file that it is required. B1 revision would
>    work, but not optimally.

The quirk can go both ways.  eg, we can detect that we *aren't* on an A0
and need to remove the compatible string.

> So i would prefer not to explicitly enable the quirk, but determine at
> run time if the quirk is needed for the SoC revision it is running on.

I agree, but that is Linux-centric.  We need to handle it coherently in
the binding docs for *BSD, bootloaders, etc.

I suggest we update the binding to allow using the compatible string,
and advise that to avoid end-user frustration, implementations should
detect the SoC revision at runtime and either add or remove the
compatible string.

thx,

Jason.
--
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/