linux-kernel - Re: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440

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]

Message-ID: <20120423100106.GB19192@pengutronix.de>
Date:	Mon, 23 Apr 2012 12:01:06 +0200
From:	Wolfram Sang <w.sang@...gutronix.de>
To:	Karol Lewandowski <k.lewandowsk@...sung.com>
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>, ben-linux@...ff.org,
	thomas.abraham@...aro.org, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	linux-samsung-soc@...r.kernel.org,
	Tomasz Stanislawski <t.stanislaws@...sung.com>,
	kyungmin.park@...sung.com, broonie@...nsource.wolfsonmicro.com
Subject: Re: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440

Hi Karol,

> >>> ... and this one, if we declare a new compatible-entry for exynos4?
> >>
> >> It is not strictly related to Exynos4 SoCs. Exynos4 SoC has 8 standard s3c2440 style
> >> i2c controllers and one additional, internal controller for HDMIPHY, which needs 
> >> some workarounds in the driver. Maybe the quirk should be named 'broken timeout 
> >> detection'
> > 
> > I was wondering since you do what I suggested for platform devices already:
> > 
> > +               .name           = "s3c2440-hdmiphy-i2c",
> > +               .driver_data    = QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO,
> 
> 
> Here I've done it this way for compatibility with legacy driver and
> board(s).

Understood.

> Device tree is new interface, and I thought that it would be better
> to describe things explicitly and separately from device type.
> 
> Right now these properties are used only on S3C2440, but I don't
> consider it highly unlikely to see these on S3C**** in future.

My experience also says that it easily can get even worse :(

> Tomasz had similar doubts when I've posted patch that checked these
> quirks only for S3C2440:
> 
>   http://permalink.gmane.org/gmane.linux.drivers.i2c/10305
> 
> Thus, I've chosen properties and not separate type.

I understand this reasoning. I still differ, though. Think about my
above example about things getting worse. Then, you'd need another
quirk-property for $FLAW. Later, $FLAW is still there, but the timeout
issue was fixed. That would mean, the poor device-tree making person has
to know which quirks to select for this version of the controller. Just
specifying that it is the HDMI-phy and not a regular I2C controller is
much more convenient, and the driver will figure the rest.

> It's easy to introduce compat string (see below), but given above
> I'm afraid that we might end up adding -hdmiphy- variant for every
> new version of i2c controller.

I'd be fine with that, given that the upcoming hdmiphy versions will not
need all the same set of quirk-flags. I think we want that "quirk lookup
table" fixed in the driver and not encoded in the device tree where
people could get it wrong. Also, the quirks are nothing a board maker
can select from; it is implicit as soons as you want the HDMIPHY on that
SoC, thus the compatible-entry should be enough of a description.

I am not the ultimate expert about bindings, though, and am open for
corrections (I feel kinda confident on this issue, though ;))

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)