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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 Mar 2012 17:54:33 +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 15.03.2012 13:56, Mark Brown wrote:

> On Thu, Mar 15, 2012 at 11:04:56AM +0100, Karol Lewandowski wrote:
> 
>> 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).
> 
> Another option is to change the type to be a pointer to a struct with
> quirk flags in it.


Sure, that's possible.   However, I don't find it any simpler than
using  bitmasks.  Quite to contrary - I consider it redundant to
bring new structure into existence when simple uint does the trick
just fine (IMHO, of course).

If you consider code to be inherently less readable because of this
approach I'll rework it.  If it's not a such big deal for you I would
prefer to keep it as is.

Thanks!
-- 
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/