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: <201204201558.48987.arnd@arndb.de>
Date:	Fri, 20 Apr 2012 15:58:48 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Roland Stigge <stigge@...com.de>
Cc:	"Lars-Peter Clausen" <lars@...afoo.de>, jic23@....ac.uk,
	gregkh@...uxfoundation.org, grant.likely@...retlab.ca,
	rob.herring@...xeda.com, linux-iio@...r.kernel.org,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	Kevin Wells <kevin.wells@....com>,
	Srinivas Bakki <srinivas.bakki@....com>, arm@...nel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RESEND v3] iio: Add device tree support to LPC32xx ADC

On Friday 20 April 2012, Roland Stigge wrote:
> In the above case, the situation is as follows:
> 
> * NXP has LPC3220, LPC3230, LPC3240 and LPC3250 (differing in SRAM size
>   and in the existence of its Ethernet and LCD controllers)
> * The ADC controller is present in every single one of those
> * We already have "lpc32xx" in the kernel everywhere
> * Current state is that NXP isn't planning to issue LPC32xx without ADC
> * I'm providing a lpc32xx.dtsi file to be used by all LPC32xx variants.
>   This one is referencing the above "compatible" string. Splitting up
>   in all possible numbers (see below) doesn't help much, here.
> 
> What would you prefer?
> 
> +static const struct of_device_id lpc32xx_adc_match[] = {
> +       { .compatible = "nxp,lpc3220-adc" },
> +       { .compatible = "nxp,lpc3230-adc" },
> +       { .compatible = "nxp,lpc3240-adc" },
> +       { .compatible = "nxp,lpc3250-adc" },
> +       {},
> +};

This looks ok to me.

> What is a better strategy here?

One way we sometimes do these things is to match only the earliest
model, e.g. nxp,lpc3220-adc, and put that one and the new model
into the device tree, to state the the device is compatible with
both the original implementation and the new one.

	Arnd
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ