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

[Karol Lewandowski <k.lewandowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]

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