linux-kernel - Re: [PATCH 2/3] i2c-s3c2410: Rework device type handling

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]

Date:	Thu, 15 Mar 2012 11:04:56 +0100
From:	Karol Lewandowski <k.lewandowsk@...sung.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	ben-linux@...ff.org, thomas.abraham@...aro.org,
	m.szyprowski@...sung.com, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linux-samsung-soc@...r.kernel.org, t.stanislaws@...sung.com,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH 2/3] i2c-s3c2410: Rework device type handling

On 14.03.2012 18:29, Mark Brown wrote:

> On Tue, Mar 13, 2012 at 05:54:38PM +0100, Karol Lewandowski wrote:
> 
>>  - replace s3c24xx_i2c_type enum with plain unsigned int that can
>>    hold not only device type but also hw revision-specific quirks
> 
> Would it not be clearer to just have explicit flags for the quirks (eg,
> as a set of bitfield flags)?

That would work on runtime but we also need to initialize this
somehow.  The way it was done today on non-dt platforms is via platform
device variants, i.e. (taken from 3rd patch):

@@ -1128,6 +1161,9 @@ static struct platform_device_id s3c24xx_driver_ids[] = {
 	}, {
 		.name		= "s3c2440-i2c",
 		.driver_data	= TYPE_S3C2440,
+	}, {
+		.name		= "s3c2440-hdmiphy-i2c",
+		.driver_data	= TYPE_S3C2440 | FLAG_HDMIPHY | FLAG_NO_GPIO,

Ability to address above scenario was sole motivation for this change.
Without it one would need either need separate type (e.g. 
TYPE_S3C2440_HDMIPHY) or setting flags based just on device name.

Introducing separate type (TYPE_S3C2440_HDMIPHY) has been our original
attempt to solve this issue.  However, this required adding explicit
checks to driver code all over the place (if (type == S3C2400 ||
type == S3c2440_HDMIPHY).

Thus, I felt that sqeezing quirks into type is a bit cleaner approach.

Regards,
-- 
Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
--
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/